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Preface 


Intended Audience 

This manual is of primary interest to current OpenVMS VAX users who are 
considering the addition of an OpenVMS AXP system to their computing 
environment and to users who are planning to migrate OpenVMS VAX 
applications to OpenVMS AXP systems. 

Document Structure 

This manual consists of the following chapters and an index: 

• Chapter 1 describes the similarities and differences between OpenVMS 
VAX and OpenVMS AXP and some of the new features introduced for both 
systems. 

• Chapter 2 describes how OpenVMS VAX and OpenVMS AXP systems can 
interoperate in networks and VMSclusters. 

• Chapter 3 lists the features available with the OpenVMS AXP Version 6.1 
operating system and the availability of selected Digital optional software 
products. It also lists some of the third-party applications that are available 
on OpenVMS AXP systems and describes the migration products and services 
available from Digital. 

• Chapter 4 describes how to assess the portability of an OpenVMS VAX 
application. It also discusses the differences between the OpenVMS VAX and 
the OpenVMS AXP programming environments and presents guidelines for 
new program development on OpenVMS VAX. 

Associated Documents 

To find out more about topics discussed in this manual, refer to the following 
table for the topic and related document. 

Topic 

Debugger features that contribute to 
migration 

DECnet for OpenVMS AXP 
DECnet for OpenVMS AXP utilities 

Delta/XDelta changes for OpenVMS AXP 


Document 

OpenVMS Debugger Manual 

DECnet for OpenVMS Networking Manual 

DECnet for OpenVMS Network Management 
Utilities 

OpenVMS Delta/XDelta Debugger Manual 


IX 


Device drivers, user-written, for 
Open VMS AXP 


DPML (Digital Portable Mathematics 
Library) 

Help Message Utility 

Linker changes for Open VMS AXP 
MACRO-64 assembler 

PALcode 

Planning for migration 

Porting applications written in mid- and 
high-level languages 

Porting VAX MACRO applications 
SDA commands for Open VMS AXP 
Security 

Translating Open VMS VAX images into 
OpenVMS AXP images 

System management differences and 
similarities between OpenVMS AXP and 
OpenVMS VAX 

VAXcluster and VMScluster systems 

VMScluster system restrictions 


Creating an OpenVMS AXP Step 2 Device 
Driver from a Step 1 Device Driver 

Creating an OpenVMS AXP Step 2 Device 
Driver from an OpenVMS VAX Device Driver 

OpenVMS AXP Device Support: Reference 
Digital Portable Mathematics Library 

OpenVMS System Messages: Companion 
Guide for Help Message Users 

OpenVMS Linker Utility Manual 

MACRO-64 Assembler for OpenVMS AXP 
Systems Reference Manual 

Alpha Architecture Reference Manual 

Migrating to an OpenVMS AXP System: 
Planning for Migration 

Migrating to an OpenVMS AXP System: 
Recompiling and Relinking Applications 

Migrating to an OpenVMS AXP System: 
Porting VAX MACRO Code 

OpenVMS AXP System Dump Analyzer Utility 
Manual 

OpenVMS Guide to System Security 

DECmigrate for OpenVMS AXP Systems 
Translating Images 

A Comparison of System Management on 
OpenVMS AXP and OpenVMS VAX 

VMScluster Systems for OpenVMS 

Guidelines for VMScluster Configurations 
OpenVMS AXP Version 6.1 Release Notes 


Conventions 

In this manual, every use of OpenVMS AXP means the OpenVMS AXP operating 
system, every use of OpenVMS VAX means the OpenVMS VAX operating system, 
and every use of OpenVMS means both the OpenVMS AXP operating system and 
the OpenVMS VAX operating system. 

The following conventions are used in this manual: 

boldface text Boldface text represents the introduction of a new term or the 

name of an argument, an attribute, or a reason (user action 
that triggers a callback). 

Boldface text is also used to show user input in Bookreader 
versions of the manual. 

italic text Italic text emphasizes important information and indicates 

complete titles of manuals and variables. Variables include 
information that varies in system messages (Internal error 
number ), in command lines ( /PRODUCER=rcarae), and in 
command parameters in text (where device-name contains up 
to five alphanumeric characters). 


x 


UPPERCASE TEXT 


numbers 


Uppercase text indicates a command, the name of a routine, 
the name of a file, or the abbreviation for a system privilege. 

A hyphen in code examples indicates that additional 
arguments to the request are provided on the line that follows. 

All numbers in text are assumed to be decimal, unless 
otherwise noted. Nondecimal radixes—binary, octal, or 
hexadecimal—are explicitly indicated. 
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Overview 


This chapter describes: 

• Lineage of OpenVMS AXP 

• Similarities and differences at the DCL level 

• Similarities and differences between OpenVMS VAX and OpenVMS AXP in 
the end-user, system management, and programming environments 

1.1 Introduction 

The purpose of this manual is to provide OpenVMS VAX users with the 
information they need to assess the impact of adding one or more OpenVMS 
AXP Version 6.1 systems to their computing environments. The manual focuses 
on the similarities and differences between OpenVMS AXP Version 6.1 and 
OpenVMS VAX Version 6.1. 

OpenVMS AXP runs on Digital’s AXP computers, which are reduced instruction 
set computers (RISC). OpenVMS AXP systems provide as much compatibility 
as possible with OpenVMS VAX systems without compromising the advantages 
offered by the Alpha AXP architecture. OpenVMS VAX customers can use 
the RISC technology of OpenVMS AXP with little change in their computing 
environment. 

Experienced OpenVMS VAX system managers will find their knowledge and 
most of their practices transferable to the OpenVMS AXP environment. Many 
OpenVMS AXP system managers compare the degree of change to that introduced 
by VAX VMS Version 5.0. 

Many Digital customers use OpenVMS VAX to run their applications that require 
high standards of availability, scalability, and data integrity. They depend on 
its reliability, robust engineering, and leadership features, such as VAXcluster 
systems. Digital anticipates that many of its customers, as their computing needs 
increase, will add OpenVMS AXP systems to their computing environments. 
Digital recognizes that this is an evolutionary process and will differ from 
customer to customer. Digital is committed to providing a clear coexistence 
environment and migration path between OpenVMS VAX and OpenVMS AXP. 

1.2 Lineage of OpenVMS AXP 

In 1978, Digital Equipment Corporation released Version 1.0 of the VMS 
operating system. Each new release since Version 1.0 represents a balance 
between compatibility with earlier releases and the introduction of new features 
and new technology that enable users to do their work more cost-effectively. A 
recent development in this evolution was the introduction of OpenVMS AXP in 
November 1992. 
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Overview 

1.2 Lineage of OpenVMS AXP 


Since the release of OpenVMS AXP Version 1.0, which was based on VMS Version 
5.4—2, additional OpenVMS VAX features have been added to each release of 
OpenVMS AXP. The latest release of OpenVMS AXP, Version 6.1, succeeds 
OpenVMS AXP Version 1.5. 

OpenVMS VAX Version 6.1 and OpenVMS AXP Version 6.1 are functionally 
equivalent, with some minor exceptions, as noted in this manual. For the 
purposes of this manual, functional equivalence is defined to mean software that 
provides the same type of functionality although the software implementation or 
user interface may vary slightly between OpenVMS VAX and OpenVMS AXP. 

1.3 DIGITAL Command Language (DCL) 

The DIGITAL Command Language (DCL), the standard user interface to 
OpenVMS, remains essentially unchanged with OpenVMS AXP. All commands 
and qualifiers available on OpenVMS VAX are also available on OpenVMS 
AXP, except for a few, as shown in Appendix A. In addition, a few qualifiers are 
available only on OpenVMS AXP, as shown in Appendix A. 

1.3.1 DCL Help 

DCL help is available on OpenVMS AXP. Most of the DCL help text is common to 
both OpenVMS AXP and OpenVMS VAX systems. For a few topics, information 
that is specific to OpenVMS VAX and information that is specific to OpenVMS 
AXP is included in the display for both systems. This system-specific information 
is identified by the names VAX and AXP. 

1.3.2 DCL Command Procedures 

DCL command procedures that use commands, qualifiers, and lexical functions 
available on OpenVMS VAX will continue to work on OpenVMS AXP systems 
without change, except for command procedures that contain those few qualifiers 
not available on OpenVMS AXP. 

1.4 End-User’s Environment 

The end-user’s environment on OpenVMS AXP Version 6.1 is virtually the same 
as that on OpenVMS VAX Version 6.1, as described in the following sections. 

1.4.1 Databases 

Standard Digital databases, such as DEC Rdb for OpenVMS, function the same 
on OpenVMS VAX and OpenVMS AXP systems. Most third-party databases that 
are available for OpenVMS VAX are also available for OpenVMS AXP. Many of 
them are shown in Table 3—3. 

1.4.2 DECforms 

The DECforms interface is unchanged. Applications that use the predecessor 
to DECforms, TDMS, can be moved to OpenVMS AXP with the aid of a TDMS 
emulator or a TDMS converter. The VAX TDMS Emulator for OpenVMS and the 
VAX TDMS to DECforms Converter for OpenVMS VAX are produced by Praxa 
Limited of Melbourne, Australia and available through Digital. 
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1.4 End-User’s Environment 


1.4.3 DECwindows Motif 

DEC windows Motif on OpenVMS AXP is unchanged from DECwindows Motif on 
OpenVMS VAX except for the addition of support for a font server and scalable 
fonts on OpenVMS AXP systems. For more information about these features, see 
Managing DECwindows Motif for OpenVMS Systems. 

1.4.4 Editors and Formatter 

The EVE and EDT editors are unchanged. EVE is the default editor for 
OpenVMS VAX and for OpenVMS AXP. EDT was the default editor for OpenVMS 
VAX prior to Version 6.0. 

The TECO editor and the DSR formatter are also provided with OpenVMS AXP. 
They, too, are unchanged. 

1.4.5 Help Message Utility 

The Help Message utility, a new feature for OpenVMS VAX Version 6.0, was 
first introduced on OpenVMS AXP Version 1.0. It enables users to access online 
descriptions of system messages on a character-cell terminal (including DECterm 
windows). 

Help Message operates through a DCL interface that accesses message 
descriptions in a text file. This text file is derived from the latest version of 
the OpenVMS system messages documentation and, optionally, from other source 
files, including user-supplied message documentation. For more information 
about Help Message, see OpenVMS System Messages: Companion Guide for Help 
Message Users. 

1.4.6 Password Generator 

Both OpenVMS VAX and OpenVMS AXP have random password generators, 
which can be used in place of passwords created by users. However, the random 
password generator on OpenVMS AXP systems has a new mechanism for 
generating passwords. This new mechanism produces nonsense passwords such 
as dramnock, inchworn , mycousia , and pestrals that seem “natural” to users. It 
makes possible the future development of language-specific random passwords. 
The list of possible passwords presented by an OpenVMS AXP system is not 
hyphenated. 

1.5 System Manager’s Environment 

Most of the OpenVMS VAX Version 6.1 system management utilities, command 
formats, and tasks are identical in the OpenVMS AXP environment. 

There are some differences that must be considered to properly set up, maintain, 
secure, and optimize OpenVMS AXP systems and to establish proper network 
connections. These differences fall into three broad categories: 

• Implementation differences for common components 

• Components available only on OpenVMS VAX 

• Components available only on OpenVMS AXP 

The differences are briefly described in this section and in greater detail in A 
Comparison of System Management on OpenVMS AXP and OpenVMS VAX and 
the OpenVMS AXP Version 6.1 Release Notes. 
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1,5 System Manager’s Environment 


1-5.1 Implementation Differences for Common Components 

The components described in this section exist on both OpenVMS VAX and 
Open VMS AXP systems, but the implementations on VAX and AXP differ, or the 
OpenVMS VAX implementation differs from earlier versions of OpenVMS VAX. 

1.5.1.1 Disk Quotas 

You might need to increase disk quotas on OpenVMS AXP disks that store 
translated OpenVMS VAX images and native OpenVMS AXP images. Translated 
images are OpenVMS AXP executable images produced by the VAX Environment 
Software Translator (VEST), the major component of DECmigrate (described in 
Section 1.6.6 and in Section 3.8). Translated images require more disk space 
because each image includes both AXP code and the original VAX code. Native 
OpenVMS AXP images require more disk space because RISC images typically 
contain more instructions and code to establish the linkage between procedure 
calls. The default values for related memory quotas have been adjusted on 
OpenVMS AXP systems. 

1.5.1.2 I/O Subsystem Configuration Commands 

On OpenVMS VAX systems, the System Generation utility (SYSGEN) is used to 
configure the I/O subsystem, as shown in Table 1—1. On OpenVMS AXP systems, 
SYSGEN is used for some configuration tasks, and the System Management 
utility (SYSMAN) and the AUTOGEN command procedure are used for others, as 
shown in Table 1—1. 


Table 1-1 A Comparison of I/O Subsystem Configurations 



OpenVMS VAX 

OpenVMS AXP 

SYSGEN 

Modify system parameters 1 

Load page and swap files 

Create additional page files 
Create additional swap files 

Load device drivers 

Modify system parameters 1 
Load page and swap files 
Create additional page files 
Create additional swap files 

SYSMAN 

Not used 

Load device drivers 

1 Although SYSGEN is available for modifying system parameters, Digital recommends that you 
use AUTOGEN and its data files instead, or that you use SYSMAN between boots, for dynamic 
parameters. 


OpenVMS VAX command procedures that use commands such as 
SYSGEN AUTOCONFIGURE ALL must be modified if they are copied to 
OpenVMS AXP systems as part of your migration effort. 

1.5.1.3 Menu-Driven Maintenance Procedure 

OpenVMS VAX Version 6.1 and OpenVMS AXP Version 6.1 introduce a 
replacement for the standalone BACKUP utility used on earlier versions of 
OpenVMS VAX and OpenVMS AXP systems. It is a menu-driven procedure 
which enables you to enter a DCL environment, from which you can perform 
backup and restore operations on the system disk (instead of using standalone 
BACKUP). 

On OpenVMS AXP systems, you can also install or upgrade the operating system, 
using the POLYCENTER Software Installation (PCSI) utility, as described in the 
POLYCENTER Software Installation Utility User's Guide. 
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1.5 System Manager’s Environment 


For more detailed information about using the menu-driven procedure, see the 
following documentation: 

• On OpenVMS VAX, see the OpenVMS System Manager's Manual 

• On OpenVMS AXP, see the OpenVMS AXP Version 6.1 Upgrade and 
Installation Manual 

1.5.1.4 MONITOR POOL Command 

The DCL command MONITOR POOL used on OpenVMS VAX Version 5.5 and 
earlier systems was replaced on OpenVMS VAX Version 6.0 and on OpenVMS 
AXP Version 1.0 by the Adaptive Pool Management feature. Adaptive Pool 
Management automatically manages the creation and sizing of nonpaged pool 
lookaside lists. 

You can obtain information about nonpaged and paged dynamic pool on OpenVMS 
VAX through the use of the DCL command SHOW MEMORY and the System 
Dump Analyzer (SDA) command SHOW POOL. You can obtain the same 
information on OpenVMS AXP with the SDA command SHOW POOL and its 
qualifiers /RING_BUFFER and /STATISTICS. 

1.5.1.5 Remote Monitoring in Mixed-Version VMScluster Systems 

Remote monitoring is a feature of the Monitor utility (MONITOR) that enables 
you to monitor any node in a VMScluster system. You can do this either by 
issuing the MONITOR CLUSTER command or by adding the /NODE qualifier to 
any interactive MONITOR request. 

Due to an incompatibility in the definition of MONITOR’S collected data, remote 
monitoring is limited across nodes running different versions of OpenVMS. You 
can perform remote monitoring among certain OpenVMS VAX and OpenVMS 
AXP versions and among certain OpenVMS VAX versions only. If you attempt to 
monitor a remote node that is incompatible, the following message is displayed: 

%M0NIT0R-E-SRVMISMATCH, MONITOR server on remote node is an incompatible 
version 

If you receive this error message, you can still obtain data about the remote node 
with MONITOR. You do this by recording the data on the remote node and then 
using the MONITOR playback feature to examine it on the local node. For more 
information on the MONITOR recording and playback features, see the OpenVMS 
System Management Utilities Reference Manual. 

1.5.1.6 Name Changes for Files Supplied with the Operating Systems 

The name changes for certain files supplied with the operating system are shown 
in Table 1-2. 


Table 1-2 Operating System File Name Changes 


OpenVMS VAX Version 5.5 

OpenVMS VAX Version 6.0 
and later 

OpenVMS AXP Version 
1.0 and later 

SYSTARTUP_V5.COM 

SYSTARTUP_VMS.COM 

SYSTARTUP_VMS.COM 

VAXVMSSYS.PAR 

VAXVMSSYS.PAR 

ALPHAVMSSYS.PAR 
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1.5.1.7 Page Size 

Open VMS VAX and OpenVMS AXP systems allocate and deallocate memory for 
processes in units called pages. On OpenVMS VAX systems, a page is 512 bytes. 
On OpenVMS AXP systems, a page will be one of four values, 8K, 16K, 32K, or 
64K bytes. An OpenVMS AXP system implements only one of the four page sizes; 
the initial set of AXP computers use an 8K byte (8192 bytes) page. 

This difference in page size is significant to OpenVMS system managers in two 
ways: 

• Process quotas and limits, and system parameters might require adjustment 
to account for the additional resources (especially memory resources) users 
might require. For example, higher values might be necessary for the 
PGFLQUOTA process quota and the GBLPAGES system parameter. 

• In a number of cases, OpenVMS AXP interactive utilities present to and 
accept from users units of memory in a 512-byte quantity called a pagelet. 
Thus, one AXP pagelet is the same size as one VAX page. On an AXP 
computer with 8K byte pages, 16 AXP pagelets equal 1 AXP page. 

In your OpenVMS AXP environment, you will need to notice when page or pagelet 
values are being shown in memory displays. If a memory value represents a page 
on an AXP system, the documentation might refer to “CPU-specific pages.” This 
convention indicates possible significant differences in the size of the memory 
being represented by the page unit, depending on the AXP computer in use 
(8K, 16K, 32K, or 64K byte pages). In general, OpenVMS AXP utilities display 
CPU-specific page values when the data represents physical memory. 

Internally, for the purposes of memory allocation, deletion, and protection, 
OpenVMS AXP will round up (if necessary) the value you supply in pagelets 
to a number of CPU-specific pages. 

The use of pagelets provides compatibility for OpenVMS VAX system managers 
and application programmers who are accustomed to thinking about memory 
values in 512-byte units. In a VMScluster system with OpenVMS VAX nodes and 
OpenVMS AXP nodes, it is helpful to know that a VAX page and an AXP pagelet 
represent a common unit of 512 bytes. Also, existing OpenVMS VAX applications 
do not need to change parameters to the memory management system services 
when the applications are ported to OpenVMS AXP. 

OpenVMS AXP does not allocate or deallocate a portion of a page. The user- 
interface quantity called a pagelet is not used internally by the operating system. 
Pagelets are accepted and displayed by utilities so that users and applications 
operate with the information that each VAX page value and each AXP pagelet 
value equal a common 512-byte quantity. 

Figure 1-1 illustrates the relative sizes of a VAX page, an AXP 8K byte page, and 
an AXP pagelet. 
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Figure 1-1 Comparison of VAX and AXP Page Size 
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1.5.1.8 Security 

On AXP systems, OpenVMS contains all the security features of Open VMS 
VAX with the exception of DECnet connection auditing. OpenVMS VAX was 
successfully evaluated at the C2 level. OpenVMS AXP has not been evaluated for 
C2 compliance. 

1.5.1.9 VMScluster Systems 

A VMScluster system can consist entirely of OpenVMS AXP nodes or a 
combination of one or more OpenVMS VAX nodes and one or more OpenVMS 
AXP nodes. The system management of a VMScluster system is essentially the 
same as that of a VAXcluster system. 

For more information on VMScluster systems, see Section 2.3. 

1.5.2 Components Available Only on OpenVMS VAX 

The components described in this section exist only on OpenVMS VAX at this 
time. Many of them are planned for OpenVMS AXP, one is being considered, and 
two are not planned, as shown in Table 1-3. 


Table 1-3 Components Available Only on OpenVMS VAX 


OpenVMS VAX Component 

Status for OpenVMS AXP 

Card reader and input symbiont 

Not planned 

Dynamic load balancing 

Planned 

Full names support 

Planned 

Patch Utility 

Limited functionality under investigation 

New proxy services and new security server 

Planned 

SCSI-2 Device Support for Tagged Command 
Queuing 

Planned 

Snapshot facility 

Not planned 
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1.5.2.1 Dynamic Load Balancing 

Dynamic load balancing enhances the ability to efficiently balance the disk I/O 
workload in a VAXcluster system. 

1.5.2.2 Full Names Support 

Full names, available with DECnet/OSI, are hierarchically-structured DECnet 
node names. These names can be stored in a DECdns naming service. Full 
names on OpenVMS VAX systems can be a maximum of 255 bytes long. 

Full names are available only on OpenVMS VAX systems that are running 
DECnet/OSI. They are not available on OpenVMS AXP Version 6.1 systems 
running DECnet/OSI, although they are planned for an upcoming release. 

DECdtm requires full names support. Because OpenVMS AXP Version 6.1 does 
not support fullnames, DECdtm cannot run with OpenVMS AXP Version 6.1 and 
DECnet/OSI. However, DECdtm, using fullnames, can run on OpenVMS AXP 
Version 6.1 and DECnet for OpenVMS AXP (Phase IV). DECdtm can also run on 
OpenVMS VAX Version 6.1 with either DECnet for OpenVMS VAX (Phase IV) or 
DECnet/OSI (Phase V). 

For more information about full names support, see the OpenVMS System 
Manager's Manual , A Comparison of System Management on OpenVMS AXP 
and OpenVMS VAX, the OpenVMS VAX Version 6.1 Release Notes , and your 
DECnet/OSI documentation. 

1.5.2.3 Patch Utility 

The Patch utility is not offered on OpenVMS AXP. However, investigation is 
underway regarding support for the PATCH/ABSOLUTE function on OpenVMS 
AXP. 

1.5.2.4 New Proxy Services and Security Server 

OpenVMS VAX Version 6.1 offers four new proxy system services, a new format 
database for proxy data, and a new security server. OpenVMS VAX 6.1 uses 
these new features, regardless of whether DECnet-VAX or DECnet/OSI is being 
used. Neither OpenVMS AXP Version 6.1 nor earlier versions of OpenVMS VAX 
offer these new features. In a mixed-version or mixed-architecture VMScluster 
system, all proxy changes must be done from a VAX system running OpenVMS 
VAX Version 6.1. 

1.5.2.5 SCSI-2 Device Support for Tagged Command Queuing 

On VAX systems, OpenVMS now supports the tagged command queuing 
architecture of the SCSI-2 standard and provides an extended OpenVMS SCSI 
port interface (SPI$) for SCSI-2 devices interfaced to an NCR 53C94 controller. 
Tagged command queuing allows the class driver to pass multiple queued I/O 
requests directly to the port driver without waiting for any one I/O to complete. 
The port-queue architecture increases I/O delivery to an external SCSI-2 device 
queue allowing the device to optimize its operation. Support for tagged command 
queuing on OpenVMS AXP is planned for an upcoming release. 

For more information, see the OpenVMS VAX Version 6.1 New Features Manual. 

1.5.2.6 Snapshot Facility 

The Snapshot facility (Snapshot), sometimes referred to as Fastboot, lets you 
reduce system startup time by booting OpenVMS VAX from a saved system image 
disk file. Snapshot can be used only for a standalone system (that is, a system 
that is not in a VAXcluster environment). 

For more information, see the OpenVMS System Manager's Manual. 
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1.5.2.7 Optional Software Products Not Supported 

Some optional Digital software products that are supported on OpenVMS VAX 
are not yet supported on OpenVMS AXP Version 6.1. If you copy existing startup 
procedures from one of your OpenVMS VAX computers to an OpenVMS AXP 
computer, you must comment out the calls to the startup procedures of currently 
unsupported optional software products. 

The availability of many Digital optional software products is shown in Table 3-2. 
The Alpha AXP Applications Catalog lists all the available Digital optional 
software products and third-party applications. You can obtain a copy, in the 
United States and Canada, by calling 1-800-DIGITAL (1-800-344-4825). In other 
locations, you can obtain a copy from your Digital account representative or 
authorized reseller. 

1.5.3 Components and Functions Available Only on OpenVMS AXP 

The components and functions described in this section exist only on OpenVMS 
AXP at this time. Many of them are planned for OpenVMS VAX while others are 
being considered, as shown in Table 1-4. 


Table 1-4 Components and Functions Available Only on OpenVMS AXP 


OpenVMS AXP Component or Function 

Status for OpenVMS VAX 

DECevent utility 

Installation of the operating system with PCSI 

LAT Master V2.0 support 

RECALL additional functions 

SYSMAN I/O function for loading device drivers 

Token ring network connection support 

DEC TRNcontroller 100 and 700 support 

Under investigation 

Planned 

Planned 

Planned 

Under investigation 

Under investigation 

Planned 


For a description of the additional functions of the RECALL command, see 
Table A—1. For an example of the SYSMAN I/O function for loading device 
drivers, see Table 1—1. 

1.5.3.1 DECevent Event Management Utility 

OpenVMS AXP Version 6.1 includes the DECevent utility (DECevent), 
which provides the interface between a system user and the system’s 
event log files. DECevent allows system users to produce ASCII reports 
derived from system event entries. DECevent uses the system event log file, 
SYS$ERRORLOG:ERRLOG.SYS, as the default input file for event reporting 
unless another file is specified. 

1.5.3.2 Installation of the Operating System with PCSI 

The POLYCENTER Software Installation (PCSI) utility is provided with 
OpenVMS VAX and OpenVMS AXP. On VAX, the use of PCSI is limited to 
installing layered products. On AXP, PCSI is also used to install OpenVMS. 
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The similarities and differences in the programmer’s environment between 
Open VMS VAX Version 6.1 and Open VMS AXP Version 6.1 are outlined in this 
section and described in more detail in Chapter 4, except where noted otherwise. 
Chapter 4 also provides guidelines for developing programs that will run on both 
OpenVMS VAX and OpenVMS AXP. 

Some programming components are not available on both OpenVMS VAX and 
OpenVMS AXP They are shown in Table 1-5 and described in this section. 


Table 1-5 Programming Components Not Available on Both Systems 


Component 

On VAX 

On AXP 

Status 

Heap Analyzer in Debugger 

Yes 

No 

Under investigation for AXP 

OpenVMS AXP System-Code 
Debugger 

No 

Yes 

Not planned for VAX 

Support for device drivers 
written in C 

No 

Yes 

Not planned for VAX 


The same types of program development tools that you are accustomed to using 
on OpenVMS VAX are available on OpenVMS AXP systems including the Linker 
utility, the Librarian utility, the OpenVMS Debugger (also known as the symbolic 
debugger), the Delta/XDelta Debugger, and run-time libraries, including the 
parallel processing run-time library (PPL RTL). 

Before moving any OpenVMS VAX applications to an OpenVMS AXP system, 
Digital recommends that you become familiar with the following differences in 
the OpenVMS AXP program development environment. 

1.6.1 RISC Architecture of Alpha AXP 

The RISC architecture of Alpha AXP differs from the complex instruction set 
computer (CISC) architecture of the VAX. The differences are particularly 
apparent when multiple processes or multiple execution threads in the same 
process access the same region of memory An asynchronous system trap (AST) 
routine whose execution preempts the processing of a main routine is one example 
of concurrent threads within a single process. 

The VAX architecture, through its microcode, provides instruction semantic 
guarantees that the Alpha AXP architecture does not. Complex atomic operations 
and synchronization guarantees incur overhead that RISC architectures are 
designed to avoid. 

For example, on a VAX computer, you can perform complex memory operations 
atomically and can access data at byte and word memory locations. If your code 
contains such VAX architectural dependencies, you likely will need to either use a 
compiler qualifier that mitigates the dependencies or make changes to your code. 

1.6.2 Floating-Point Data Types 

Support for the H_float floating-point and full-precision D_float floating-point 
data types has been eliminated from the hardware to improve overall system 
performance. 

AXP hardware converts D_float floating-point data to G_float floating-point data 
for processing. On VAX computers, the D_float floating-point data type has 56 
fraction bits (D56) and 16 decimal digits of precision. 
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The H_float floating-point and D_float floating-point data types can usually be 
replaced by the G_float floating-point data type or one of the IEEE formats. 
However, if you require the H_float floating-point data type or the extra precision 
of the D_float floating-point data type, you may have to translate part of your 
application with DECmigrate for OpenVMS AXP. 

1.6.3 User-Written Device Drivers 

Both OpenVMS VAX and OpenVMS AXP support user-written device drivers. 
The overall structure of device drivers is the same on each architecture but 
source changes are required to migrate a device driver from one architecture to 
the other. 

For more information, see Section 4.3.4. 

1.6.4 Compilers 

Most DEC compilers (and the MACRO-64 assembler) are available on OpenVMS 
AXP Version 6.1 as shown in the following list: 

• DEC Ada 

• DEC BASIC 

• DEC C 

• DEC C++ 

• DEC COBOL 

• DEC Fortran 

• DEC Pascal 

• MACRO-32 

• DEC OPS5 

• DEC PL/I 

These compilers are also available on OpenVMS VAX Version 6.1, except for the 
MACRO-32 compiler, which converts VAX MACRO code into AXP machine code. 
The MACRO—32 compiler is bundled with OpenVMS AXP to ease migration. 

The differences between the compilers on VAX and AXP may require some minor 
changes to your code. For more information, see Chapter 4. 

1.6.5 Native Assembler 

The native assembler, MACRO—64, is not bundled with the OpenVMS AXP 
operating system. Instead, it is available as an optional software product. For 
more information, see Section 4.3.3. 

1.6.6 DECmigrate for OpenVMS AXP 

DECmigrate for OpenVMS AXP is an optional Digital software product that 
translates OpenVMS VAX images into OpenVMS AXP images. If the native 
compiler for your application is not available, you can translate it. 

DECmigrate for OpenVMS AXP can also be used to analyze code to determine 
how easy or difficult it would be to migrate it. For more information about 
DECmigrate for OpenVMS AXP, see Section 3.8. 
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1.6.7 Linker 

The way certain linking tasks, such as creating shareable images, are performed 
is different on OpenVMS AXP systems. You may need to modify the LINK 
command used to build your application. For example, instead of creating a 
transfer vector file for a shareable image, you must create a linker options file 
and declare universal symbols by specifying the SYMBOL_VECTOR= option. For 
more information, see Section 4.3.1. 

1.6.8 Librarian 

The Librarian utility provides a new qualifier, /VAX. The /VAX qualifier directs 
the Librarian utility to create an OpenVMS VAX object module library when used 
with the /CREATE and /OBJECT qualifiers or an OpenVMS VAX shareable image 
library when used with the /SHARE qualifier. OpenVMS AXP libraries are the 
default on OpenVMS AXP systems. For more information, see the OpenVMS 
Command Definition, Librarian, and Message Utilities Manual. 

1.6.9 Debuggers 

The OpenVMS Debugger provides several features that facilitate debugging 
OpenVMS AXP code. These features address the architectural differences that 
exist between VAX and AXP computers. For example, the /UNALIGNED_DATA 
qualifier used with the SET command enables you to detect unaligned data. 

On VAX, the OpenVMS Debugger offers a new facility, the Heap Analyzer, that 
represents graphically, in real time, the utilization of dynamic memory (heap). 
This can be used for user-mode utility or application code and is only available on 
OpenVMS VAX at this time. 

For more information about the OpenVMS Debugger, see Section 4.3.5. 

The Delta/XDelta Debugger provides several new commands and changes 
to existing commands for debugging OpenVMS AXP programs. For more 
information, see Section 4.3.6 

The OpenVMS AXP System-Code Debugger lets you use the familiar OpenVMS 
Debugger interface to observe and manipulate system code interactively as it 
executes. For more information, see Section 4.3.7. 

1.6.10 System Dump Analyzer 

The System Dump Analyzer on OpenVMS AXP systems is almost identical to 
the utility provided on OpenVMS VAX systems. Most commands, qualifiers, and 
displays are the same. For more information, see Section 4.3.8. 

The Crash Log Utility Extractor (CLUE) is available on both OpenVMS VAX 
and OpenVMS AXP. It was created to make the information for debugging crash 
dumps more accessible and more useful. For more information, see Section 4.3.9. 

1.6.11 Vector Processing 

Vector processors were an option for VAX 6500 and VAX 9000 computers to 
provide higher performance for numerically intensive applications. AXP 
computers and later versions of VAX computers do not provide this option 
because their basic designs provide high-speed calculations. 
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If you used this option for Fortran applications, you do not have to make any 
changes to your code for it to run on AXP computers or later models of VAX 
computers. You only have to recompile it with the DEC Fortran for Open VMS 
AXP compiler. If you used vector-specific support in VAX MACRO applications, 
you will need to make changes to your code before recompiling it with the 
MACRO-32 compiler for OpenVMS AXP. 

Image files whose source files included vector instructions cannot be translated. 
The VAX Environment Software Translator (VEST) component of DECmigrate 
does not support them. 
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This chapter describes the similarities and differences, where they exist, of the 
following topics: 

• Interoperability of OpenVMS VAX and OpenVMS AXP on a DECnet network 
and on a TCP/IP network 

• DECnet network features and management 

• Interoperability of OpenVMS VAX and OpenVMS AXP in a VMScluster 

2.1 Interoperability on a Network 

OpenVMS AXP and OpenVMS VAX systems can interoperate in a network, 
sharing system resources and enabling communication with local and remote 
nodes, in the same way that OpenVMS VAX systems interoperate. Network 
management of OpenVMS AXP nodes is also similar to network management of 
OpenVMS VAX nodes. However, some differences exist due to architectural and 
implementation differences. 

2.1.1 Interoperability Using DECnet for OpenVMS AXP 

DECnet for OpenVMS and DECnet/OSI are used to establish networking 
connections with other OpenVMS VAX and OpenVMS AXP nodes. Both products 
are available for OpenVMS VAX systems and for OpenVMS AXP systems. 

DECnet for OpenVMS, formerly known as DECnet-VAX, implements Phase IV of 
DNA (Digital Network Architecture). The features of DECnet for OpenVMS AXP 
are similar to those of the DECnet-VAX software that is part of VMS Version 
5.4-3, with a few exceptions, as noted in Section 2.2. 

DECnet/OSI for OpenVMS, which implements Phase V of DNA, is an ISO- 
compliant product. DECnet/OSI for OpenVMS conforms to networking standards 
defined by the International Organization for Standardization (ISO). DECnet/OSI 
for OpenVMS features include: 

• Larger networks than the 64,449-node limit in Phase IV networks 

• A longer, more descriptive format for node names 

• Use of a local name database or a distributed namespace database 

Full names support for DECnet/OSI is available on OpenVMS VAX Version 6.1 
and is planned for an upcoming OpenVMS AXP release. 

File transfers over the DECnet network, including copying and printing, can 
be done between OpenVMS VAX and OpenVMS AXP systems running either 
DECnet for OpenVMS or DECnet/OSI. 
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There is full interoperability for DECnet remote login between OpenVMS VAX 
and OpenVMS AXP nodes running DECnet for OpenVMS or DECnet/OSI, via the 
SET HOST command. 

2.1.2 Interoperability Using DEC TCP/IP Services for OpenVMS 

DEC TCP/IP Services for OpenVMS implements the TCP/IP protocols. This 
product provides interoperability and resource sharing between OpenVMS 
systems, UNIX systems, and other systems that support the TCP/IP and NFS 
protocol suites. The resource sharing includes the services that users of DECnet 
are familiar with: remote file access, remote terminal access, remote command 
execution, remote printing, mail, and application development. 

File transfers over a TCP/IP network, enabled by DEC TCP/IP Services for 
OpenVMS, are the same between OpenVMS AXP systems and UNIX systems as 
they are between OpenVMS VAX systems and UNIX systems. 

Remote login over a TCP/IP network is the same between OpenVMS AXP systems 
and UNIX systems as it is between OpenVMS VAX systems and UNIX systems. 

2.1.3 Network Interfaces 

Most of the network protocols, buses, and interconnects that are supported on 
OpenVMS VAX systems are also supported on OpenVMS AXP systems, as shown 
in the following tables. 

2.1.3.1 Network Protocols 

The network protocols supported on OpenVMS VAX and OpenVMS AXP systems 
are shown in Table 2-1. 


Table 2-1 Network Protocol Support 


OpenVMS VAX 

OpenVMS AXP 

Protocol 

Versions V5.5-2, 6.0, & 6.1 

Versions 1.5, 1.5-1 HI, & 6.1 

DECnet (Phase IV) 

Yes 

Yes 

DECnet/OSI (Phase V) 

Yes 

Yes 

LAD/LAST 

Yes 

Yes 

LAT 

Yes 

Yes 

LAVC 

Yes 

Yes 

TCP/IP 1 

Yes 

Yes 

X.25 

Yes 2 

Yes 3 


1 Provided by DEC TCP/IP Services for OpenVMS (formerly named the VMS/ULTRIX Connection 
(UCX)). 

2 For OpenVMS VAX Version V5.5-2, provided by VAX PS.I.; for OpenVMS VAX Version 6.0 and 
Version 6.1, provided by DECnet/OSI. 

3 For OpenVMS AXP Version 1.5 and Version 1.5-1H1, provided by DEC X.25 Client for OpenVMS 
AXP software. Running this software, a node can connect to an X.25 network via an X.25 router on 
the same local area network. For OpenVMS AXP Version 6.1, provided by DECnet/OSI. 


2.1.3.2 Buses 

The buses supported on OpenVMS VAX and OpenVMS AXP systems are shown 
in Table 2-2. Support is also dependent on the computer model. 
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Table 2-2 Bus Support 


Protocol 

OpenVMS VAX 

Versions V5.5-2, 6.0, & 6.1 

OpenVMS AXP 

Versions 1.5, 1.5-1 HI, & 6.1 

Bi-bus 

Yes 

No 1 

DSSI 

Yes 

Yes 

EISA bus 

No 

Yes 2 

Futurebus+ 

No 

Yes 2 

Q-bus 

Yes 

No 1 

SCSI 

Yes 

Yes 

TURBOchannel 

Yes 

Yes 

UNIBUS 

Yes 

No 2 

VME 

Yes 

CO 

O 

£ 

XMI 

Yes 

Yes 


1 Support not planned. 

2 Except for OpenVMS AXP Version 1.5 
3 A custom Digital offering is available. 


2.1.3.3 Interconnects 

The interconnects (including their respective protocols and drivers) that are 


supported on OpenVMS VAX and OpenVMS AXP systems are shown in 

Table 2-3. 

Table 2-3 Interconnect Support 

Interconnect 

DECnet 1 

TCP/IP 2 

LAT 

Cluster: Computer 
to Computer 

Computer to 
Tape or Disk 

Asynch Line 

V 

- 

- 

- 

- 

Synch Line 

V 

- 

- 

- 

- 

Cl 

V 

- 

- 

A,V 

A,V 

DSSI 

- 

- 

- 

A,V 

A,V 

Ethernet 

A,V 

A,V 

A,V 

A,V 

- 

FDDI 3 

A,V 

A,V 

A,V 

a 4 ,v 

- 

SCSI 

- 

- 

- 

- 

A,V 

Token Ring 

- 

A 5 

- 

- 

- 


1 Provided by DECnet for OpenVMS. 

2 Provided by DEC TCP/IP Services for OpenVMS (formerly named the VMS/ULTRIX Connection 
(UCX)). 


3 Boot support is not available for all computer models. 

4 OpenVMS AXP Versions 1.5 and 1.5-1H1 do not use an FDDI adapter for cluster communications, 
but Ethernet bridging to FDDI backbones can be used. OpenVMS AXP Version 6.1 can use an FDDI 
adapter for cluster communications. 

5 Available only on OpenVMS AXP Version 6.1. 

Key 

A = OpenVMS AXP Version 1.5, Version 1.5-1H1, and Version 6.1 
V = OpenVMS VAX Version V5.5-2, Version 6.0, Version 6.1 
- = Neither 
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While FDDI is supported as an interconnect, it does not provide boot support 
for any VAX computer models. However, it does provide boot support for several 
Alpha AXP computer models, as shown in Table 2-4. 


Table 2-4 FDDI Boot Support for OpenVMS AXP Version 6.1 



Adapter 

Alpha AXP 
Computer 

Boot Support 

EISA 


DEFEA 

2000 

No 

XMI 


DEMFA 

7000 

Yes 


Futurebus+ 



DEFAA 

7000 

Yes 


DEFAA 

4000 

No 

TURBOchannel 


DEFZA 

3000-300 

No 


DEFZA 

3000-others 

Yes 


PMAF-CA 

3000-300 

No 


PMAF-CA 

3000-others 

Yes 


DEFTA 

3000-all 

Yes 


PMAF-FA 

3000-all 

Yes 


PMAF-FD 

3000-all 

Yes 


PMAF-FS 

3000-all 

Yes 


PMAF-FU 

3000-all 

Yes 


Configurations without FDDI boot support have two limiting circumstances in which they must also 
be wired to an Ethernet circuit: 

1. If operating system software installations or updates are to be performed from an Infoserver. 

2. If the system is to be a VMScluster satellite (unlikely for larger systems). 


2.2 DECnet Network Features and Management 

The similarities and differences in the network features and management 
for DECnet for OpenVMS AXP (Phase IV) and for DECnet-VAX for 
VMS Version 5.4-3 are described in this section. 

2.2.1 Similarities 

The features and management of DECnet for OpenVMS AXP (Phase IV) are 
similar to that of DECnet-VAX for VMS Version 5.4-3, with some exceptions. 
The following list shows the features and management tasks that are identical: 

• DECnet objects 

• DECnet Test Sender/DECnet Test Receiver utility (DTS/DTR) 

• Downline load and upline dump operations 
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• Event logging 

• Ethernet monitor (NICONFIG) 

• File access listener (FAL) 

(Identical between AXP nodes and between AXP and VAX nodes.) 

• Loopback mirror testing 

• NETCONFIG_UPDATE.COM procedure 

• Node name rules 

• Product Authorization Key (PAK) name for end-node license (DVNETEND) 

• SET HOST capabilities 

(Identical between AXP nodes and between AXP and VAX nodes.) 

• Size of network 

• Task-to-task communication 

2.2.2 Differences 

The features and management of DECnet for OpenVMS AXP (Phase IV) are 
similar to that of DECnet—VAX for VMS Version 5.4—3, with some exceptions. 
Table 2-5 shows the features and management tasks that are different. 


Table 2-5 Differences of DECnet Features and Management Tasks 

Feature or Task OpenVMS VAX OpenVMS AXP 


Cluster alias 


Configuring DECnet 
databases and starting 
OpenVMS AXP 
computer’s access to 
the network 


Lines supported 

NETCONFIG.COM 
procedure (part for 
specifying a router) 


Level 1 and Level 2 routing 
supported on nodes acting as 
routers for a cluster alias. 


Cl, asynch (DDCMP), Ethernet, 
and FDDI 

NETCONFIG.COM prompts you, 
“Do you want to operate as a 
router?” 


Only Level 1 routing supported on 
nodes acting as routers for a cluster 
alias. 

Process for both is the same but 
subject to the routing limitations 
and the lack of support for Cl, 
DDCMP, the Distributed Name Service 
(DNS) node name interface, VAX 
PS.I., and certain Network Control 
Program (NCP) utility command 
parameters. The functions of the 
SYS$MANAGER: STARTNET.COM 
procedure are similar. 

Ethernet and FDDI 

NETCONFIG.COM does not 
prompt you. You have to manually 
enable Level 1 routing. Otherwise, 
NETCONFIG.COM is the same on 
OpenVMS AXP systems. 

(continued on next page) 
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Table 2-5 (Cont.) Differences of DECnet Features and Management Tasks 


Feature or Task 

OpenVMS VAX 

OpenVMS AXP 

Network management via 
Network Control Program 
(NCP) utility and the 
network management 
listener (NML) object 


In many cases, the NCP commands 
and parameters are identical. 

However, the NCP command 
parameters for SET and SHOW 
operations for DDCMP, full host-based 
routing, the Distributed Name Service 
(DNS), and VAX P.S.I. have no effect 
on OpenVMS AXP 

Product Authorization 

Key (PAK) name for 
cluster alias routing 
support 

DVNETRTG 

DVNETEXT 

Routing 

Level 1 and Level 2 routing are 
supported. 

Level 1 routing is supported only on 
nodes acting as routers for a cluster 
alias. Level 2 routing is not supported. 

VAX P.S.I. 

Supported 

Not supported. For DECnet for 
OpenVMS AXP Version 1.5, DEC X.25 
Client for OpenVMS AXP replaces VAX 
P.S.I. 


For more information about the system management differences between DECnet 
for OpenVMS (Phase IV) on OpenVMS VAX and OpenVMS AXP systems, and 
the system management differences between DECnet/OSI for OpenVMS VAX and 
OpenVMS AXP systems, see A Comparison of System Management on OpenVMS 
AXP and OpenVMS VAX . 

For more information about both DECnet products (DECnet for OpenVMS and 
DECnet/OSI) for OpenVMS VAX and OpenVMS AXP systems, see the DECnet 
for OpenVMS Networking Manual , DECnet for OpenVMS Network Management 
Utilities , and your DECnet/OSI documentation. 

2.3 Interoperability in a VMScluster System 

VMScluster systems for OpenVMS AXP offer all the software features of 
VAXcluster systems. All the related VAXcluster software products except 
the Business Recovery Server (BRS) are available for OpenVMS AXP nodes. 
(Formerly named the Multi-Datacenter Facility, BRS is scheduled for release in 
June 1994.) 

For configurations with VAX and AXP nodes, separate system disks are required 
for booting OpenVMS VAX and OpenVMS AXP systems. Cross-architecture 
satellite booting is enabled for systems running OpenVMS VAX Version 6.1 and 
OpenVMS AXP Version 6.1 and DECnet for OpenVMS (Phase IV). VAX boot 
nodes can provide boot service to AXP satellites, and AXP boot nodes can provide 
boot service to VAX satellites. Cross-architecture upgrading is not enabled. 

2.3.1 VMScluster Configuration Support 

OpenVMS AXP Version 6.1 and OpenVMS VAX Version 6.1 provide two levels 
of support for mixed-version and mixed-architecture VMScluster systems. 
Warranted and migration are the two support levels. 
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Warranted support means that Digital has fully qualified the two versions 
coexisting in a VMScluster system and will answer all problems identified by 
customers using these configurations. Warranted support is provided for several 
pairs of OpenVMS VAX and OpenVMS AXP versions. 

Migration support means that Digital has qualified the versions for use together 
in configurations which are migrating in a staged fashion to a newer version of 
OpenVMS VAX or OpenVMS AXP. 

Migration support is a superset of the rolling upgrade support provided in earlier 
releases of OpenVMS and is available for pairs that are not warranted. Problem 
reports submitted against these configurations will be answered by Digital. 
However, in exceptional cases Digital may request that you move to a warranted 
configuration as part of answering the problem. Migration support will help 
customers move to warranted VMScluster version pairs, with minimal impact on 
their cluster environments. 

Table 2-6 shows the level of support provided for all possible version pairings. 


Table 2-6 Support Levels for Version Pairs in VMSclusters 


Versions 

AXP V6.1 

VAX V6.1 

VAX V6.0 

AXP VI.5 

VAX V5.5-2 

Migration 

Migration 

Migration 

Warranted 

AXP VI.5 

Migration 

Migration 

Warranted 

- 

VAX V6.0 

Migration 

Migration 

- 

- 

VAX V6.1 

Warranted 

- 

- 

- 


Note that Digital does not support the use of more than two versions in a 
VMScluster at a time. In many cases more than two versions will successfully 
operate, but Digital cannot commit to resolving problems experienced with such 
configurations. 

For more VMScluster information, see the documentation listed in Table 2-7. 


Table 2-7 VMScluster Documentation Sources 


Topic 

Documentation 

Configuration rules and 
restrictions 

Software Product Description of VMScluster Software 
for OpenVMS AXP and OpenVMS VAX 

Configuration guidelines 

Guidelines for VMScluster Configurations 

Differences between managing 
VAXclusters and VMSclusters 

A Comparison of System Management on OpenVMS 
AXP and OpenVMS VAX 

All other VMScluster 
information 

VMScluster Systems for OpenVMS and the OpenVMS 
AXP Version 6.1 Release Notes 
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This chapter provides information that will help you decide when to include 
one or more OpenVMS AXP systems in your computing environment and which 
migration resources to use. The following topics are discussed: 

• Availability of base operating system features 

• Timetable for the availability of Digital optional software products 

• Available third-party applications 

• Application migration paths 

• Hardware and software investment protection program 

• Migration services, training, software, and documentation 

• AXP systems on the Internet 

Most of the OpenVMS VAX features and many of the Digital optional software 
products and third-party applications are already available on OpenVMS AXP. 

To help protect your investment in Digital products, Digital offers a single 
uniform upgrade program known as the ADVANTAGE-UPGRADE program. 
Digital also provides a full range of migration resources so that you can select 
what is appropriate for your organization. The offerings include an array of 
migration services, training, software, documentation, and access to AXP systems 
on the Internet. 

3.1 Availability of Base Operating System Features 

Table 3-1 shows the availability, on OpenVMS AXP, of selected features of the 
OpenVMS VAX base operating system. The list is not complete; it represents the 
features that are most important to Digital customers. For more information, 
contact your Digital account representative or authorized reseller. 


Table 3-1 Status of Selected OpenVMS VAX Base Operating System Features 
on OpenVMS AXP 


Feature 

OpenVMS AXP V6.1 

Adaptive pool management 1 

Yes 

Batch and print queuing system 2 

Yes 

Class scheduler system services 1 

Yes 

1 OpenVMS VAX Version 6.0 feature. 

2 OpenVMS VAX Version 5.5 feature. 

(continued on next page) 
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Table 3-1 (Cont.) Status of Selected OpenVMS VAX Base Operating System 
Features on OpenVMS AXP 


Feature 

OpenVMS AXP V6.1 

C2 Security 1 

Yes 3 

DECdtm 

Yes 

DECthreads 2 

Yes 

Debugger 

Yes 

EMA base system support 

Yes 

Extended LAT integration 2 

Yes 

DECnet/OSI full names support 4 

No 5 

Heap Analyzer in the OpenVMS Debugger 4 

No 

Help Message 1 

Yes 

Infoserver booting 

Yes 

ISO 9660 support 1 

Yes 

LMF VI.I 2 

Yes 

Media management enhancements (MME) 4 

Yes 

MS CP dynamic load balancing 1 

No 5 

MoveFile function with enhancements 2 

Yes 

Multiple queue manager support 1 

Yes 

POLYCENTER Software Installation (PCSI) 
utility 

Yes 

SCSI-2 Tagged Command Queuing (TCQ) 6 

No 5 

Snapshot facility 1 

No 

Symmetric Multiprocessing (SMP) 

Yes 

TPU and EVE 

Yes 

Virtual I/O cache for standalone machines 

Yes 

Virtual I/O cache clusterwide 

Yes 

VMScluster support 

Yes 

VMScluster support: FDDI interconnect of AXP 
systems 

Yes 

VMScluster support: TMSCP serving by AXP 
systems 

Yes 

X-terminal support 

Yes 

User-written device driver support 

Yes 7 

1 OpenVMS VAX Version 6.0 feature. 

2 OpenVMS VAX Version 5.5 feature. 


3 C2 security features available but not yet evaluated by the U.S. government. Auditing DECnet 

connections is not supported on AXP. 

4 OpenVMS VAX Version 6.1 feature. 

5 Planned for a future release. 

6 OpenVMS VAX Version 5.5-2H4 feature. 

7 Step 2 drivers. 
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3.2 Timetable for Digital Optional Software Products 

Many Digital optional software products were available on earlier versions of 
OpenVMS AXP and many more are available now. Table 3-2 shows some of the 
optional software products already released and some that will be available soon 
Table 3-2 does not list all Digital optional software, but it does list the products 
that are of interest to the largest number of Digital customers. 

Note that the releases are cumulative. For example, the CD-ROM for Digital 
optional software products released in June 1994 contains all the optional 
products that have been released for OpenVMS AXP. 

_ Note _ 

Any optional software products running on OpenVMS AXP Version 1.5 or 
earlier that contain device drivers will not run on OpenVMS AXP Version 
6.1, because the device driver interface changed significantly. The device 
drivers in such applications must be revised. Although many products are 
listed as Already Released, the versions that can run on OpenVMS AXP 
Version 6.1 may be different. 

A Digital layered product CD-ROM was released concurrently with 
OpenVMS AXP Version 6.1. All layered products on this CD-ROM run on 
OpenVMS AXP Version 6.1. The CD-ROM includes all Digital OpenVMS 
AXP software products (including products previously released that were 
upgraded to run on OpenVMS AXP Version 6.1). 


Digital software products are released quarterly. The Alpha AXP Applications 
Catalog lists all available applications: Digital optional software and third-party 
applications. The catalog is updated regularly. To obtain this catalog in the 
United States and Canada, call 1-800-DIGITAL (1-800-344-4825). In other 
locations, contact your Digital account representative or authorized reseller. 

To find out when products not listed in the catalog will be available, contact your 
Digital account representative or authorized reseller. 


Table 3-2 Availability of Selected Digital Optional Software Products 


Already Released 

Jan. - June ’94 

July - Dec. ’94 

Language and Application Development 

DATATRIEVE 

DEC Ada 

DEC C 

DEC C++ 

DEC COBOL 

DEC OPS5 

DEC Pascal 

DEC RALLY 

DECelx Real Time Tools 
DEC BASIC 

DEC PL/I 

Forte 


Middleware 


(continued on next page) 
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Table 3-2 (Cont.) Availability of Selected Digital Optional Software Products 


Already Released 

Jan. - June ’94 

July - Dec. ’94 

Middleware 

ObjectBroker 

DEC AVS 

DEC GKS 

DECmessageQ 

DEC PHIGS 

DQS 

Open 3D 

POSIX 1 

SQL Access Services 

DEC EDI 

POSIX 2 

VMSclusters and Associated Software 

VMSclusters 

DECram for OpenVMS 

RMS Journaling 

VMScluster Console System 
Volume Shadowing (host-based) 3 
DECamds (driver) 

Storage Works RAID 
(Disk Striping) 


Networking 

TCP/IP Services 

DECnet Phase IV 

DECnet/OSI (end node) 

X.25 4 


Transaction Processing and Information Management 

ACCESSWORKS 

ACMS Desktop Client 

ACMS runtime 

CDD/Repository 

Data Distributor 

DBMS 

DECforms 

DECobject database 

DEC Rdb 

SQL Multimedia 

ACMS development 
Rdb/Expert 

Instant SQL 

RTR 

DB Integrator 

DBA Workcenter 

End-User Tools 

DEC Notes 

VTX 


Other 



1 POSIX 1003.1 and 1003.2; XPG3 Base Branding. 


2 Final POSIX 1003.1b, 1003.1c, and 1003.2 standards; XPG4 BASE profile branding of components. 
3 HSC-based shadowing will not be ported. 

4 Supports DECnet, and Intel and Windows NT clients. 


(continued on next page) 
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Table 3-2 (Cont.) Availability of Selected Digital Optional Software Products 


Already Released 

Jan. - June ’94 

July - Dec. ’94 

Other 

PATHWORKS Server 5 
POLYCENTER Performance 
Data Collector 

POLYCENTER Scheduler 
POLYCENTER SW DIS 6 client 
DEC X.25 Client 

POLYCENTER File 
Optimizer 

PATHWORKS Server 7 

QFD Expert 

Business Recovery Server 8 

ALL-IN-1 Integrated 
Office System 


5 Supports MS-DOS, OS/2, and windows clients. 


6 POLYCENTER Software Distribution (formerly called Remote System Manager). 

7 Client/native/relay function. 

8 Formerly called Multi-Datacenter Facility (MDF) 


3.3 Available Third-Party Applications 


More than 2000 third-party applications are currently available for 
OpenVMS AXP. Some of them are shown in Table 3-3. 


The Alpha AXP Applications Catalog , which is updated regularly, lists all the 
available third-party applications and Digital optional software products. In 
the United States and Canada, you can obtain a copy by calling 1-800-DIGITAL 
(1-800-344-4825). In other locations, you can obtain the catalog from your Digital 
account representative or authorized reseller. To find out when products not 
listed in the catalog will be available, contact your Digital account representative 
or authorized reseller. 


Table 3-3 Sampling of Third-Party Applications Available as of June 1994 

Application Company 


ACUMATE 

AD ABAS 

ade EKO 

ade INV 

ade T/D 

ADINA 

ALK-GIAP 

Anvil 5000 

Application Browser 

ARC/INFO 

ASPEN PLUS 

Auto. Library System 

BEV-PAK 

Blood Bank Systems 



Kenan Technologies 

Software AG of North America, Inc. 

Adedata AB. 

Adedata AB. 

Adedata AB. 

ADINA R&D, INC. 

AED Graphics GmbH 

Manufacturing and Consulting Services, Inc. 
Hypersoft Corporation 

Environmental Systems Research Institute, 
Inc. 

Aspen Technology, Inc. 

Dynix, Inc. 

Turn-Key Distribution Systems, Inc. 

Antrim Corporation 

(continued on next page) 
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Table 3-3 (Cont.) Sampling of Third-Party Applications Available as of June 
1994 


Application 


Company 


BROKERMAX 

Business Intelligence Network (BIN) 

Cadim/EDB 

CADRA-III 

Client Server Interfaces 

DADisp 

DL Pager 

ECLIPSE 

Financial Systems 

FlexiLab System 

FlexiRad 

FOCUS for Alpha 

Gembase Open Systems 4GL 

GENSTAT 5 

GLIM 

GRAFkit 

Graphics Language Interpreter 

IAS 

IBS-90 

IMPALA 

Information Support Systems 

"Integra" Application Management 
Environment 

Integrated Graphics System 

Integration Services 

IPS 

MANMAN (including Process) 

MANTIS 

MAPS 

MARGO 

Mathematica 

MESSIDOR 

Mobile 

Multinet 

NAG FORTRAN Library 
NAG Graphics Library 
NAGWave Fortran 90 Compiler 


Citymax Integrated Information System Ltd. 
Henco Software, Inc. 

EIGNER + PARTNER GmbH 
ADRA Systems, Inc. 

Sybase, Inc. 

DSP Development Corporation 
Datalogics, Inc. 

Intera Information Technologies 

Antrim Corporation 

Sunquest Information Systems, Inc. 

Sunquest Information Systems, Inc. 
Information Builders, Inc. 

Ross Systems, Inc. 

Numerical Algorithms Group, Ltd. 

Numerical Algorithms Group, Ltd. 

Centera Information Systems, Inc. 

Centera Information Systems, Inc. 

CODA, Incorporated 
Winter Partners 
EEC SYSTEMS, INC. 

Antrim Corporation 

G.C. McKeown & Co. (UK) Ltd. 

Datalogics, Inc. 

Antrim Corporation 
CODA, Incorporated 
ASK Computer Services, Inc. 

Cincom Systems, Inc. 

Logica Industry Limited 
SEMA GROUP-PROGICIELS 
Wolfram Research, Inc. 

SEMA GROUP-PROGICIELS 
KINGSTON_SCL LTD. 

TGV, Inc. 

Numerical Algorithms Group, Ltd. 

Numerical Algorithms Group, Ltd. 

Numerical Algorithms Group, Ltd. 

(continued on next page) 
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Table 3-3 (Cont.) Sampling of Third-Party Applications Available as of June 
1994 


Company 

Software AG of North America, Inc. 
NETRON, Inc. 

NETRON, Inc. 

Oasys 

Oracle Corporation 
Oracle Corporation 
Oracle Corporation 
Oracle Corporation 
Datalogics, Inc. 

Excalibur Technology 
SEMA GROUP-PROGICIELS 

SEMA GROUP-PROGICIELS 

SEMA GROUP-PROGICIELS 
Uniface Int. 

Cognos, Inc. 

Progress Software Corporation 
Progress Software Corporation 

Progress Software Corporation 
Progress Software Corporation 
Progress Software Corporation 


Application 

NATURAL 

NETRON/CAP 

NETRON/Client 

Oasys 680x0 Cross Tools 

ORACLE V7 (Developer’s release) 

ORACLE V7 (Production release) 

Oracle Financials and Human Resources 
Oracle Manufacturing 
Page Station/X 
PixTex/EFS 

PLEIADES HOSPITAL 
ADMINISTRATION 

PLEIADES HRM/PRIVATE AND 
PUBLIC SECTORS 

PLEIADES LOCAL COMMUNITIES 

Polyserver 

PowerHouse 4GL 

PROGRESS 4GL/RDBMS 

PROGRESS Application and 
Development Environment 

PROGRESS Developer’s Toolkit 

PROGRESS FAST TRACK 

PROGRESS RESULTS Query/Reporting 
Tool 

PROMIS 

Promix Distribution Series 

Promix Manufacturing Series 

Renaissance CS Financial Series 

Renaissance CS Human Resource Series 

RSC-PR Payroll 

SAP R/3 System 

SAS System 

SmartStar Report Painter 
SmartStar Vision 
STADEN Package 
STUDENTS+ 

Supercache 

SuperDisk 


Promis Systems Corporation 
Ross Systems, Inc. 

Ross Systems, Inc. 

Ross Systems, Inc. 

Ross Systems, Inc. 

Resource Systems Corporation 
SAP of America, Inc. 

SAS Institute, Inc. 

SmartSystems (UK) Ltd. 

SmartStar Corporation 
Medical Research Council 
J.H. Leskin Associates, Inc. 

EEC Systems, Inc. 

EEC Systems, Inc. 

(continued on next page) 
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Table 3-3 (Cont.) Sampling of Third-Party Applications Available as of June 
1994 


Application 

Company 

SUPRA 

Cincom Systems, Inc. 

Sybase Lifecycle Tools 

Sybase, Inc. 

Sybase SQL Server 

Sybase, Inc. 

Synchrony 

Henco Software, Inc. 

TCM-EMS Time Critical Manufacturing 
System V 

Effective Management Systems, Inc. (EMS) 

TGRAF-X 

Grafpoint, Inc. 

Timeserver 

Pilot Software Ltd. 

TROPOS 

Strategic Systems International 

Unidata RDBMS 

Unidata, Inc. 

Uniface Development Environment 

Uniface and Uniface Int. 

UNIGRAPHICS 

Electronic Data Systems Corporation 

VAX TDMS Emulator for OpenVMS 

Praxa Limited 

VAX TDMS to DECforms Converter for 
OpenVMS VAX 

Praxa Limited 

WIN/TCP 

Wollongong 

Wisconsin Sequence Analysis Package 

Genetics Computer Group 

WITNESS (U.S.) 

AT&T ISTEL 


3.4 Application Migration Paths to OpenVMS AXP 

Table 3-4 shows several paths for application migration from OpenVMS VAX to 
OpenVMS AXP systems. 


Table 3-4 Application Migration Paths 


AXP VI .0 

AXP VI .5 

AXP V6.1 

VAX V5.4-2 

Recommended 

Recommended 

Supported 1 

VAX V5.4-3 

Recommended 

Recommended 

Supported 1 

VAX V5.5, V5.5-1 

Supported 1 

Recommended 

Supported 1 

VAX V5.5-2 

Supported 1 

Recommended 

Recommended 

VAX V6.0 

Not Recommended 

Supported 1 

Recommended 

VAX V6.1 

Not Recommended 

Not Recommended 

Recommended 


1 Supported means that most applications will run, but applications that depend on features that are 
not available either in a particular version of OpenVMS AXP or in an OpenVMS AXP compiler will 
not run or will not run correctly. 


3.5 Hardware and Software Investment Protection Programs 

Digital offers hardware and software investment protection in a single, uniform 
upgrade program known as the ADVANTAGE-UPGRADE Program. By offering 
all of Digital’s upgrade selections under a single program, selection of the proper 
and most cost-effective upgrade has become simpler. 


3-8 


Migration When You’re Ready 
3.5 Hardware and Software Investment Protection Programs 


While the names have changed, the upgrade features remain the same. For 
example, you can: 

• Lock in a not-to-exceed price for upgrading to Alpha AXP systems (within a 
specified period of time) when you purchase new VAX or MIPS computers. 

• Purchase a simple AXP upgrade from older VAX computers or use the trade-in 
credit from your existing VAX computers. 

• Trade in the original operating system licenses for 75% credit towards an 
alternative operating system that will run on the same computers. This gives 
you the flexibility of switching to another operating system at a later date. 

For Digital layered software products, user-based licenses are valid across 
hardware architectures so no special program has been introduced. New 
clusterwide and capacity-based licenses are significantly discounted. For more 
information, contact your Digital account representative or authorized reseller. 

3.6 Migration Services 

Digital customizes the level of service to meet your needs. The migration services 
available include the following: 

• Orientation Service (Order number: QS-ALPAA-CA) 

• Detailed Analysis Service 

• Migration Support Service 

• Project Planning Service 

• Custom Project Service 

The Orientation Service is available from DECdirect (1-800-DIGITAL). (The order 
number listed for this service is in effect in the United States.) The remaining 
services are tailored to the needs of your organization. 

To determine which services are appropriate for you, contact your Digital account 
representative or authorized reseller or call 1-800-832-6277 (within the United 
States) or 1-603-884-8990 (outside the United States). 

3.6.1 Orientation Service 

The Orientation Service helps you understand the issues involved in migrating 
an application from OpenVMS VAX to OpenVMS AXP systems. This package is 
recommended for all Alpha AXP migration customers. 

3.6.2 Detailed Analysis Service 

The Detailed Analysis Service provides a customized methodology for planning 
the migration of an application from OpenVMS VAX to OpenVMS AXP systems. 

A Digital consultant conducts a detailed investigation of the customer’s 
application, highlights items that may impact the migration effort and schedule, 
and produces a detailed migration assessment plan. This service is recommended 
for all customers who would like help with their migration. 

3.6.3 Migration Support Service 

The Migration Support Service is provided by a Digital migration expert who 
assists in the migration project. This service includes on-site technical consulting 
at the level you require. 


3-9 


Migration When You’re Ready 
3.6 Migration Services 


3.6.4 Project Planning Service 

The Project Planning Service is provided by a Digital consultant. The consultant 
provides the following: 

• Information that you need to understand the size and scope of a migration 
project 

• Information that you need to develop a detailed migration strategy based on 
your requirements 

• Detailed migration project plan 

3.6.5 Custom Project Service 

The Custom Project Service results in a total turnkey migration. It is 
recommended for customers who want Digital to migrate their entire application. 

3.6.6 Business Partner Development Assistance Centers 

Business Partner Development Assistance (BPDA) centers provide migration 
services worldwide, as shown in Table 3-5. Migration experts staff the centers 
and assist Digital’s business partners with their porting efforts. 

For detailed information on migration services, contact your Digital account 
representative or authorized reseller, or call 1-800-832-6277 or 1-603-884-8990. 


Table 3-5 Locations of BPDA Centers 


Europe 

United States 

Asia 

Basingstoke 

Detroit 

Hong Kong 

Munich 

Marlboro 

Tokyo 

Paris 

Palo Alto 



3.7 Migration Training 

Digital Customer Training offers several seminars and courses to provide 
migration training to third-party application developers and end users. The first 
course in the following list is designed for technical or MIS managers, and the 
others are designed for experienced OpenVMS VAX programmers: 

• Alpha AXP Planning Seminar —2 days, EY-L570E-SO 

• Migrating HLL Applications to OpenVMS Alpha AXP —3 days, EY-L577E-LO 

• Migrating MACRO-32 Applications to OpenVMS AXP —2 days, EY-L578E-LO 

To obtain a schedule and enrollment information in the United States, call 
1-800-332-5656. In other locations, contact your Digital account representative or 
authorized reseller. 

3.8 Migration Software 

Compilers are available on OpenVMS AXP for almost all the languages supported 
on OpenVMS VAX. Most programs can be recompiled and relinked for execution, 
in native mode, on OpenVMS AXP. For more information, see Chapter 4. 
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In addition to the OpenVMS AXP compilers, Digital also offers DECmigrate for 
OpenVMS AXP, a Digital optional software product. DECmigrate is used for the 
following purposes: 

• To analyze code to determine how easy or difficult it might be to translate it 

• To translate images for which you have no sources or whose native compiler 
is not yet available on OpenVMS AXP systems 

The VAX Environment Software Translator (VEST) component of DECmigrate 
translates the VAX binary image file into a native AXP image. The translated 
image runs under the Translated Image Environment (TIE) on an AXP computer. 
(TIE is a shareable image that is included with the OpenVMS AXP operating 
system.) Translation does not involve running an OpenVMS VAX image under 
emulation or interpretation (with certain limited exceptions). Instead, the new 
OpenVMS AXP image contains Alpha AXP instructions that perform operations 
identical to those performed by the instructions in the original OpenVMS VAX 
image. 

A translated image generally runs as fast on an AXP computer as the original 
image runs on a VAX computer. However, a translated image does not benefit 
from the optimizing compilers that take full advantage of the Alpha AXP 
architecture. Therefore, a translated image typically runs about 25% to 
40% as fast as a native OpenVMS AXP image. The primary causes for this 
reduced performance are unaligned data and the extensive use of complex VAX 
instructions. 

For more information on image translation and VEST, see DECmigrate for 
OpenVMS AXP Systems Translating Images. 

3.8.1 Mixing Native AXP and Translated Images 

You can mix migration methods among the individual images that comprise an 
application, that is, you can recompile some modules with the native OpenVMS 
AXP compilers and translate other modules with DECmigrate. You can also 
partially translate an application as one stage in a migration. This enables 
you to run and test an application on an AXP computer before it is completely 
recompiled. 

For more information about interoperability of native AXP and translated VAX 
images within an application, see Migrating to an OpenVMS AXP System: 
Recompiling and Relinking Applications. 

3.9 Migration Documentation 

Digital offers several migration documents. Migration information is also 
provided in the language user’s guides for the DEC compilers. The differences 
in the DEC compilers between OpenVMS AXP and OpenVMS VAX systems 
are described in the DEC compilers’ users’ guides. In some guides, such as the 
DEC C User's Guide for OpenVMS Systems , the differences are described in the 
context of the description of a language element; in other guides, such as the 
DEC COBOL User Manual , the differences are described in separate appendixes. 

The following list describes the migration manuals. Table 3-6 lists their order 
numbers. 

• AXP Migration Kit, which consists of the following documents: 

— Migrating to an OpenVMS AXP System: Planning for Migration 
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This manual describes the general characteristics of RISC architectures, 
compares the Alpha AXP architecture to the VAX architecture, and 
presents an overview of the migration process and a summary of 
migration tools provided by Digital. The information in this manual 
is intended to help you define the optimal migration strategy for your 
application. 

— Migrating to an OpenVMS AXP System: Recompiling and Relinking 
Applications 

This manual provides detailed technical information for programmers 
who must migrate mid- and high-level language applications to OpenVMS 
AXP systems. It describes how to set up a development environment 
to facilitate the migration of applications, helps programmers identify 
application dependencies on elements of the VAX architecture, and 
introduces compiler features that help resolve these dependencies. 
Individual sections of this manual discuss specific application 
dependencies on VAX architectural features, data porting issues (such as 
alignment concerns), and the process of migrating VAX shareable images. 

— Migrating to an OpenVMS AXP System: Porting VAX MACRO Code 

This manual describes how to use the MACRO—32 compiler for OpenVMS 
AXP to port VAX MACRO code to an OpenVMS AXP system. It 
describes the features of the compiler, presents a methodology for 
porting VAX MACRO code, identifies nonportable coding practices, and 
recommends alternatives to such practices. The manual also provides 
detailed descriptions of the compiler qualifiers, directives, built-ins, and 
the system macros created for porting to an OpenVMS AXP system. 

— A Comparison of System Management on OpenVMS AXP and OpenVMS 
VAX 

This manual compares system management on OpenVMS AXP and 
OpenVMS VAX systems. It is intended for experienced system managers 
who need to learn quickly how specific tasks differ or remain the same on 
OpenVMS AXP and OpenVMS VAX. 

• DECmigrate for OpenVMS AXP Systems Translating Images 

This manual describes the VAX Environment Software Translator (VEST) 
utility, discussed in Section 3.8. It describes how to use VEST to convert 
most user-mode OpenVMS VAX images to translated images that can run 
on OpenVMS AXP systems; how to improve the run-time performance of 
translated images; how to use VEST to trace OpenVMS AXP incompatibilities 
in an OpenVMS VAX image back to the original source files; and how to 
use VEST to support compatibility among native and translated run-time 
libraries. 

• Creating an OpenVMS AXP Step 2 Device Driver from a Step 1 Device Driver 

This manual describes how to convert a Step 1 OpenVMS AXP device driver, 
written in VAX MACRO, to a Step 2 OpenVMS AXP device driver, also 
written in VAX MACRO. 

• Creating an OpenVMS AXP Step 2 Device Driver from an OpenVMS VAX 
Device Driver 

This manual describes how to convert an OpenVMS VAX device driver— 
written in VAX MACRO—to a Step 2 OpenVMS AXP device driver, also 
written in VAX MACRO. 
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• OpenVMS AXP Device Support: Reference 

This manual provides reference material for creating OpenVMS AXP device 
drivers, and it describes the macros, system routines, and entry points used 
in converting OpenVMS VAX and Step 1 OpenVMS AXP device drivers to 
Step 2 OpenVMS AXP device drivers. 

3.9.1 How to Order Migration Documentation 

The order numbers for the AXP Migration Kit and the migration documents are 
shown in Table 3—6. 

When you purchase an OpenVMS AXP media kit, you receive the AXP Migration 
Kit in Bookreader format (DECW$BOOK) on the compact disc. When you 
purchase the printed OpenVMS AXP Standard Documentation Set, the AXP 
Migration Kit is included. You can also order this kit or any of its manuals 
separately. DECmigrate for OpenVMS AXP Systems Translating Images in 
Bookreader format accompanies the optional product, DECmigrate for OpenVMS 
AXP. To obtain a printed copy, you must order it separately. 


Table 3-6 Order Numbers for Migration Documentation 


Manual or Kit 

Order Number 

AXP Migration Kit 

QA-MT1AG-GZ 

Migrating to an OpenVMS AXP System: Planning for 
Migration 

AA-PV62 A-TE 

Migrating to an OpenVMS AXP System: Recompiling and 
Relinking Applications 

AA-PV63A-TE 

Migrating to an OpenVMS AXP System: Porting 

VAX MACRO Code 

AA-PV 64 A-TE 

A Comparison of System Management on OpenVMS AXP 
and OpenVMS VAX 

AA-PV71B-TE 

DECmigrate for OpenVMS AXP Systems Translating 
Images 

AA-PSGMB-TE 

Creating an OpenVMS AXP Step 2 Device Driver from a 
Step 1 Device Driver 

AA-Q2 8TA-TE 

Creating an OpenVMS AXP Step 2 Device Driver from an 
OpenVMS VAX Device Driver 

AA-Q2 8UA-TE 

OpenVMS AXP Device Support: Reference 

AA-Q28PA-TE 


The documentation can be ordered by telephone, by mail, and, in the United 
States, from the Electronic Store. The directions follow. 

Telephone Orders 


Continental USA, 
Alaska, or Hawaii 

Puerto Rico 

Canada 

Internation al 


Call 800-DIGITAL 

800-344-4825 

Fax: (603) 884-5597 

Call 809-781-0505 
Fax: (809) 749-8377 

Call 800-267-6215 
Fax: (613) 592-1946 

Call local Digital subsidiary or approved 
distributor 
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Direct Mail Orders 

Continental USA, 
Alaska, or Hawaii 


Puerto Rico 


Canada 


International 


Digital Equipment Corporation 

P.O. Box CS2008 

Nashua, New Hampshire 03061 

Digital Equipment Caribbean, Inc. 

3 Digital Plaza, 1st Street 

Suite 200 

Metro Office Park 

San Juan, Puerto Rico 00920 

Digital Equipment of Canada Ltd. 

Attn: DECdirect Sales 

100 Herzberg Road 

Kanata, Ontario, Canada K2K 2A6 

Contact local Digital subsidiary or approved 
distributor 


Electronic Orders, USA Only 

To place an order from the Electronic Store, dial 1-800-234-1998 using a 2400- 
or 9600-baud modem. If you need help using the Electronic Store, call 1-800- 
DIGITAL (800-344-4825). 


3.10 AXP Systems on the Internet 

As a service to the Internet community, Digital has made available two DEC 
4000 AXP systems. These systems can be used for evaluating the Alpha AXP 
architecture and for testing the features of the supporting Open VMS AXP and 
DEC OSF/1 for AXP operating systems, compilers, tools, and utilities. 

Application developers who have access to the Internet can use these systems 
to test, qualify, or port their software for the Alpha AXP architecture. Other 
Internet users interested in Alpha AXP computing are invited to log in and 
evaluate these systems. 

One DEC 4000 AXP system (Internet address: axpvms.pa.dec.com) has the 
OpenVMS operating system installed. The other DEC 4000 AXP system (Internet 
address: axposf.pa.dec.com) is running the DEC OSF/1 for AXP UNIX operating 
system. These systems can be reached either via telnet or rlogin. 

To register for an account, Internet users connect to the desired machine, log in 
as axpguest (no password), and answer the short qualifying questionnaire. Users 
are asked to read all information in the motd/login banner and comply with all 
rules for machine usage/restrictions. 

Users with questions about their accounts should send mail to Internet address: 
axpvms-system@pa.dec.com for the OpenVMS AXP system and to Internet 
address: axposf-root@pa.dec.com for the DEC OSF/1 for AXP system. 
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This chapter describes: 

• How to assess the portability of an application 

• OpenVMS AXP support for portability 

• Differences in the OpenVMS AXP programming environment 

• Guidelines for new program development for OpenVMS VAX and 
OpenVMS AXP 

In general, if your application is written in a high-level programming language, 
you should be able to run it on an AXP system with a minimum amount of effort, 
High-level languages insulate applications from dependence on the underlying 
machine architecture. In addition, for the most part, the programming 
environment on AXP systems duplicates the programming environment on VAX 
systems. Using native AXP versions of the language compilers and the Linker 
utility (linker), you can recompile and relink the source files that make up your 
application to produce a native AXP image. 

If your application is written in VAX MACRO, you may be able to run it on an 
AXP system with a minimum amount of effort, although it is more likely to 
contain some dependencies on the underlying VAX architecture, some of which 
may require your intervention. 

4.1 How to Assess the Portability of an Application 

The portability of an application depends on the language in which it is written, 
the amount of nonstandard code it might contain, the number of architectural 
dependencies it might contain, and whether a compiler is available for the 
language in which the application is written. While it is possible to introduce 
architectural dependencies in applications written in high-level languages, they 
are more likely to occur in applications written in mid- and low-level languages. 

Privileged applications, which run in inner modes or at elevated interrupt 
priority levels (IPLs), may require significant changes because of assumptions 
incorporated in the code about the internal operation of the operating system. 
Typically, such applications also require significant changes after a major release 
of the OpenVMS VAX operating system. 

Recently, Digital introduced new versions of several compilers. It is likely that 
the applications that you might want to move to an OpenVMS AXP system were 
compiled using the earlier VAX compilers. 

To assess the portability of an application, consider the following: 

• The application’s dependencies on the VAX architecture 

• The differences between the VAX and DEC language compilers 
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• The diagnostic features of the compilers and DECmigrate for OpenVMS AXP 

You may also need to identify nonstandard coding practices. They are generally 
more common in code written in lower-level languages, such as VAX MACRO. 

For information about such practices for VAX MACRO, refer to Migrating to an 
OpenVMS AXP System: Porting VAX MACRO Code. 

4.1.1 Identifying Dependencies on the VAX Architecture in Your Application 

Even if your application recompiles successfully with a compiler that generates 
native AXP code, it may still contain subtle dependencies on the VAX 
architecture. The OpenVMS AXP operating system has been designed to provide 
a high degree of compatibility with OpenVMS VAX; however, the fundamental 
differences between the VAX and AXP architectures can create problems for 
applications that depend on certain VAX architectural features. The following list 
highlights those areas of your application you should examine. 

• Check the data declarations contained in your application. The high-level 
language data types you selected to represent data items on an OpenVMS 
VAX system may not be the best choice on an OpenVMS AXP system. In 
particular, consider the following: 

— Data packing —Applications on VAX systems typically use the smallest 
available data type to represent a data item to achieve efficient use of 
memory resources. For various reasons, using larger data types may be 
more efficient on OpenVMS AXP systems. For example, unaligned data 
can take 100 times longer to process than aligned. 

— Data-type selection —The Alpha AXP architecture supports most of 
the VAX native data types; however, certain VAX data types, such as the 
H_float floating-point data type, are not supported. Check to see if your 
application depends on the size or bit representation of an underlying 
native data type. 

— Shared access to data —Check any writeable data item that is accessed 
by multiple threads of execution. The VAX architecture includes 
instructions that can perform certain complex operations, such as 
incrementing a variable, that appear as a single, noninterruptable 
operation to other threads of execution. The Alpha AXP architecture is a 
load-store architecture that does not support atomic memory-to-memory 
modifications so different program constructs may be required. 

In addition, the VAX architecture supports instructions that can 
manipulate byte- and word-sized data in a single noninterruptable 
operation. The Alpha AXP architecture supports noninterruptable access 
only to aligned longword- or aligned quadword-sized data. 

— Buffer size —Your application may determine the size of certain data 
buffers based on the VAX page size. Different implementations of the 
Alpha AXP architecture can support 8K, 16K, 32K, or 64K byte pages. 
Search your application for the text strings “512” and “511” (or the 
hexadecimal equivalents, “200” and “IFF”) to find dependencies on the 
VAX page size. 

• Check any condition handlers your application may include. While the 
condition handling facility on OpenVMS AXP systems is functionally 
equivalent to the VAX condition handling facility, certain aspects of the 
facility have changed, such as the format of the mechanism array. In 
addition, the way in which arithmetic exceptions are reported has changed. 
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• Check for dependence on the AST parameter list. While the AST parameter 
list on OpenVMS AXP systems has the same format as on VAX systems, only 
the AST parameter field can be used. The other fields in the AST parameter 
list (contents of RO, Rl, program counter [PC], and processor status [PS]) are 
provided for compatibility only and have no subsequent use after the AST 
procedure exits. For example, on OpenVMS VAX systems, some user-written 
AST procedures are designed to change one or more of the values in the other 
fields in the AST parameter list so that these new values take effect upon 
completion of the AST procedure. Because ASTs are handled differently on 
OpenVMS AXP systems, such changes by the AST procedure to the other 
fields in the AST parameter list have no effect. Anything an AST procedure 
writes to the last four parameters on an AXP computer is lost when the AST 
procedure exits. 

For more information about dependencies on the VAX architecture, see Migrating 
to an OpenVMS AXP System: Recompiling and Relinking Applications and 
the user’s guides for the particular language. For applications written in 
VAX MACRO, see Migrating to an OpenVMS AXP System: Porting VAX MACRO 
Code. 

4.1.2 Compiler Differences 

Compiler differences can exist for two reasons: differences between earlier and 
current versions of compilers running on OpenVMS VAX and differences between 
the DEC versions running on the VAX and AXP computers. The compilers 
available on OpenVMS AXP systems are intended to be compatible with their 
counterparts on OpenVMS VAX systems. The languages conform to language 
standards and include support for most OpenVMS VAX language extensions. 

The compilers produce output files with the same default file types as they do on 
OpenVMS VAX systems, such as .OBJ for an object module. 

Note, however, that some features supported by the compilers on OpenVMS VAX 
systems may not be available in the same compiler on OpenVMS AXP systems. 
For example, the OpenVMS AXP run-time libraries (RTLs) do not contain the 
routine LIB$ESTABLISH, which the OpenVMS VAX RTLs contain. Due to the 
nature of the OpenVMS AXP calling standard, setting up condition handlers is 
done by compilers. 

For those programs that need to dynamically establish condition handlers, some 
AXP languages give special treatment for apparent calls to LIB$ESTABLISH 
and generate the appropriate code without actually calling an RTL routine. The 
following languages support LIB$ESTABLISH semantics in a compatible fashion 
with the corresponding VAX language: 

• DEC C and DEC C++ 

Although DEC C and DEC C++ on OpenVMS AXP treat LIB$ESTABLISH 
as a built-in function, the use of LIB$ESTABLISH is not recommended on 
OpenVMS VAX or OpenVMS AXP systems. C and C++ programmers should 
call VAXC$ESTABLISH instead of LIB$ESTABLISH (VAXC$ESTABLISH is 
a built-in function on DEC C and DEC C++ OpenVMS AXP). 

• DEC Fortran 

DEC Fortran allows declarations to LIB$ESTABLISH and converts them to 
DEC Fortran RTL specific entry points. 

• DEC Pascal 
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DEC Pascal provides the built-in routines, ESTABLISH and REVERT, to use 
in place of LIB$ESTABLISH. If you declare and try to use LIB$ESTABLISH, 
you will get a compile-time warning. 

• MACRO-32 

The MACRO-32 compiler will attempt to call LIB$ESTABLISH if it is 
contained in the source code. 

If MACRO-32 programs establish dynamic handlers by storing a routine 
address at O(FP), they will work correctly when compiled on an OpenVMS 
AXP system. However, you cannot set the condition handler address from 
within a JSB (Jump to Subroutine) routine, only from within a CALL_ENTRY 
routine. 

In addition, some compilers on OpenVMS AXP systems support new features 
not supported by their counterparts on OpenVMS VAX systems. To provide 
compatibility, some compilers support compatibility modes. For example, the 
DEC C for OpenVMS AXP compiler supports a VAX C compatibility mode that is 
invoked by specifying the /STANDARD=VAXC qualifier. 

In some cases, the compatibility is limited. For example, VAX C implements 
built-in functions that allow access to special VAX hardware features. Since 
the hardware architecture of VAX computers differs from AXP computers, 
these built-ins are not available on DEC C for OpenVMS AXP even when the 
/STANDARD=VAXC qualifier is used. 

If you are recompiling VAX C code, either an entire application or one or more 
modules, you will want to pay particular attention to any external symbols that it 
contains. Unlike the VAX C compiler which supports one external symbol model, 
the DEC C compiler supports four models. The default external symbol that is 
produced by the DEC C compiler is not the same as the single VAX C external 
symbol. 

Furthermore, when you link such code, due to changes in the linker, if you did 
not specify the /SHARE qualifier when you recompiled the C code module, you 
will need to specify a related linker qualifier. 

For more information about compiler differences between OpenVMS VAX and 
OpenVMS AXP, refer to Migrating to an OpenVMS AXP System: Recompiling 
and Relinking Applications. For more information about the compiler differences 
for each language, refer to its documentation, especially the user’s guides and the 
release notes. For more information about the linker, refer to Section 4.3.1. 

4.2 OpenVMS AXP Support for Portability 

The OpenVMS AXP operating system and many of the optional products it 
supports, such as the DEC compilers and DECmigrate for OpenVMS AXP, 
include features that contribute to portability. Some of the features are primarily 
diagnostic while others compensate for architectural dependencies. 

4.2.1 Diagnostic Features 

The DEC compilers can produce messages that are very useful for identifying 
potential porting problems. For example, the MACRO-32 compiler provides the 
/FLAG qualifier with 10 options. Depending on which options you include, the 
compiler reports all unaligned stack and memory references, any run-time code 
generation (such as self-modifying code), branches between routines, or several 
other conditions. 
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The DEC Fortran compiler qualifier, /CHECK, produces messages about any of 
the various options you specify 

A component of DECmigrate, the VAX Environment Software Translator (VEST), 
can be used to analyze images. It can identify specific incompatibilities for an 
AXP computer. Depending on the type of incompatibility, you can choose to 
specify a compiler qualifier that will compensate for the problem or make changes 
to the code. For more information, see DECmigrate for OpenVMS AXP Systems 
Translating Images 

4.2.2 Features That Minimize Architectural Differences 

The compilers can compensate for some architectural dependencies that may exist 
in your code. For example, the MACRO-32 compiler provides the /PRESERVE 
qualifier that can preserve granularity or atomicity or both. 

The DEC C compiler provides a header file that defines macros for each data 
type. These macros map a generic data-type name, such as int64, to the machine- 
specific data type, such as -64. For example, if you must have a data type that is 
64 bits long, use the int64 macro. 

Review the documentation for your compiler to become familiar with all its 
features that facilitate migration. 

4.2.3 PALcode 

The Alpha AXP architecture does not favor a particular operating system. To 
accommodate different operating systems, it enables the creation of privileged 
architecture library code (PALcode). 

Furthermore, certain OpenVMS AXP compilers, such as C and the MACRO-32 
compiler, provide PALcode built-ins that supplement the instructions available in 
the Alpha AXP instruction set. For example, the MACRO-32 compiler provides 
built-ins that emulate those VAX instructions for which there are no Alpha AXP 
equivalents and a built-in that enables you to write your own PALcode. 

PALcode can be used to access internal hardware registers and physical memory. 
PALcode can provide direct correspondence of physical and virtual memory. For 
more information about PALcode, see the Alpha Architecture Reference Manual. 

4.3 Differences in the OpenVMS AXP Programming Environment 

Additional differences in the OpenVMS AXP program development environment 
are discussed in this section. 


4.3.1 Linker 

Once you successfully recompile your source files, you must relink your 
application to create a native AXP image. The linker produces output files 
with the same file types as on current VAX systems. For example, by default, the 
linker uses the file type .EXE to identify image files. 

Because the way in which you perform certain linking tasks is different on 
OpenVMS AXP systems, you will probably need to modify the LINK command 
used to build your application. The following list describes some of these linker 
changes that may affect your application’s build procedure. See the OpenVMS 
Linker Utility Manual for more information. 

• Declaring universal symbols in shareable images —If your application 
creates shareable images, your application build procedure probably includes 
a transfer vector file, written in VAX MACRO, in which you declare the 
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universal symbols in the shareable image. On OpenVMS AXP systems, 
instead of creating a transfer vector file, you must declare universal symbols 
in a linker options file by specifying the SYMBOL_VECTOR= option. 

• Linking against the OpenVMS executive —On OpenVMS VAX systems, 
you link against the OpenVMS executive by including the system symbol 
table file (SYS.STB) in your build procedure. On OpenVMS AXP systems, you 
link against the OpenVMS executive by specifying the /SYSEXE qualifier. 

• Optimizing the performance of images —On OpenVMS AXP systems, the 
linker can perform certain optimizations that can improve the performance 
of the images it creates. In addition, the linker can create shareable images 
that can be installed as resident images, which enhances performance. 

• Processing shareable images implicitly —On OpenVMS VAX systems, 
when you specify a shareable image in a link operation, the linker also 
processes all the shareable images to which that shareable image was linked. 
On OpenVMS AXP systems, to include these shareable images in your build 
procedure, you must explicitly specify them. 

The linker supports several qualifiers and options, listed in Table 4-1, that are 
specific to OpenVMS AXP systems. Some linker options, listed in Table 4-2, are 
not supported on OpenVMS AXP systems. 


Table 4-1 Linker Qualifiers and Options Specific to OpenVMS AXP Systems 


Qualifiers 


Description 


/DEMAND_ZERO 

/DSF 

/GST 

/INFORMATIONALS 

/NATIVE_ONLY 


Controls how the linker creates demand-zero image 
sections. 

Directs the linker to create a file called a debug 
symbol file (DSF) for use by the OpenVMS AXP 
System-Code Debugger. 

Directs the linker to create a global symbol table 
(GST) for a shareable image (the default). More 
typically specified as /NOGST when used to create 
shareable images for run-time kits. 

Directs the linker to output informational messages 
during a link operation (the default). More typically 
specified as /NOINFORMATIONALS to suppress 
these messages. 

Directs the linker to not pass along the procedure 
signature block (PSB) information, created by the 
compilers, in the image it is creating (the default). 

If /NONATIVE_ONLY is specified during linking, the 
image activator uses the PSB information, if any, 
provided in the object modules specified as input 
files to the link operation to invoke jacket routines. 
Jacket routines are necessary to allow native AXP 
images to work with translated VAX images. 

(continued on next page) 
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Table 4-1 (Cont.) Linker Qualifiers and Options Specific to OpenVMS AXP 
Systems 


Qualifiers 

Description 

/REPLACE 

Directs the linker to perform certain optimizations 
that can improve the performance of the image it is 
creating, when requested to do so by the compilers 
(the default). 

/SECTION_BINDING 

Directs the linker to create a shareable image that 
can be installed as a resident image. 

/SYSEXE 

Directs the linker to process the OpenVMS executive 
image (SYS$BASE_IMAGE.EXE) to resolve symbols 
left unresolved in a link operation. 

Options 

Description 

SYMBOL_TABLE= option 

Directs the linker to include global symbols as 
well as universal symbols in the symbol table file 
associated with a shareable image. By default, the 
linker includes only universal symbols. 

SYMBOL_VECTOR= option 

Used to declare universal symbols in AXP shareable 
images. 

Table 4-2 Linker Options Specific to OpenVMS VAX Systems 

Options 

Description 

BASE= option 

Specifies the base address (starting address) that you 
want the linker to assign to the image. 

DZRO_MIN= option 

Specifies the minimum number of contiguous, 
uninitialized pages that the linker must find in 
an image section before it can extract the pages 
from the image section and place them in a newly 
created demand-zero image section. By creating 
demand-zero image sections (image sections that do 
not contain initialized data), the linker can reduce 
the size of images. 

ISD_MAX= option 

Specifies the maximum number of image sections 
allowed in the image. 

UNIVERSAL^ option 

Declares a symbol in a shareable image as universal, 
causing the linker to include it in the global symbol 
table of a shareable image. 


4.3.2 VAX MACRO-32 Compiler for OpenVMS AXP 

The VAX MACRO-32 Compiler for OpenVMS AXP is used to convert existing 
VAX MACRO code into machine code that runs on OpenVMS AXP systems. It is 
included with OpenVMS AXP for that purpose. 

While some VAX MACRO code can be compiled without any changes, most code 
modules will require the addition of entry point directives. Many code modules 
will require other changes as well. 
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The compiler generates code that is optimized for OpenVMS AXP systems, 
but many features of the VAX MACRO language that provide the programmer 
with a high level of control make it more difficult to generate optimal code 
for OpenVMS AXP systems. For new program development for OpenVMS 
AXP, Digital recommends the use of mid- and high-level languages. For more 
information on the MACRO-32 compiler, see Migrating to an OpenVMS AXP 
System: Porting VAX MACRO Code. 

4.3.3 MACRO-64 Assembler for OpenVMS AXP 

The MACRO-64 Assembler for OpenVMS AXP systems is the native assembler 
for all AXP computers. Unlike the VAX MACRO assembler which is included with 
the OpenVMS VAX operating system, the MACRO—64 assembler is not included 
with the OpenVMS AXP operating system. It can be purchased separately. In 
general, the mid- and high-level language compilers generate higher performance 
code for OpenVMS AXP systems than the MACRO-64 assembler. Therefore, 
Digital recommends you use mid- and high-level compilers for new program 
development for OpenVMS AXP systems. For more information about the 
MACRO-64 assembler, see MACRO-64 Assembler for OpenVMS AXP Systems 
Reference Manual. 

4.3.4 User-Written Device Drivers 

OpenVMS AXP Version 6.1 introduces formal support for user-written device 
drivers and a new interface known as the Step 2 driver interface, which replaces 
the temporary Step 1 driver interface that was provided in OpenVMS AXP 
Versions 1.0 and 1.5. The Step 2 driver interface supports user-written device 
drivers in the C programming language. There is no formal support for writing 
OpenVMS VAX device drivers in C. For example, OpenVMS VAX does not provide 
.h files for internal VMS (lib) data structures. 

The Step 2 driver interface has increased the differences between OpenVMS 
AXP and OpenVMS VAX device drivers. Device driver source files written in 
VAX MACRO or Bliss can be kept common between OpenVMS AXP and VAX 
through the use of conditional compilation and user-written macros. 

The advisability of this approach depends greatly on the nature of the individual 
driver. It is likely that in future versions of OpenVMS AXP, the I/O subsystem 
will continue to evolve in directions that will have an impact on device drivers. 
This could increase the differences between OpenVMS AXP and VAX device 
drivers and add more complexity to common driver sources. For this reason, 
a fully common driver source file approach might not be advisable for the long 
term. 

Depending on the individual driver, it might be advisable to partition the driver 
into a common module and an architecture-specific one. For example, if one 
were writing a device driver that does disk compression, then the compression 
algorithm could readily be isolated into an architecture independent module. 

One could also avoid operating-system-specific data structures in such common 
modules with the intent of having some common modules across various types of 
operating systems; for example, OpenVMS, Windows NT, and OSF. 

For more information about writing OpenVMS AXP device drivers in C, see the 
OpenVMS AXP Device Support: Developer's Guide. 
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4.3.5 OpenVMS Debugger 

On OpenVMS AXP systems you can use the debugger with programs written in 
the following DEC languages: 

• Ada 

• BASIC 

• C 

• C++ 

• COBOL 

• Fortran 

• MACRO-32 (compiled with the MACRO-32 compiler) 

• MACRO-64 

• Pascal 

• DEC PL/I 

The OpenVMS Debugger includes several features that address the architectural 
differences of OpenVMS AXP code. These enable you to more easily debug code 
that you are porting to OpenVMS AXP systems. For example, you can use the 
/UNALIGNED_DATA qualifier with the SET command to cause the debugger to 
break directly after any instruction that accesses unaligned data (such as a load 
word instruction which accesses data that is not on a word boundary). 

You can use the /RETURN qualifier with the SET command for any routine. It 
is not limited to routines called with a CALLS or CALLG instruction as it is 
on an OpenVMS VAX system. For more information about features specific to 
OpenVMS AXP systems, see the OpenVMS Debugger Manual. 

4.3.6 Delta/XDelta Debugger 

The Delta/XDelta Debugger (DELTA/XDELTA), running on OpenVMS AXP 
systems, provides enhancements to existing commands and several new 
commands necessitated by the Alpha AXP architecture. The enhancements 
include the display of base registers in decimal instead of hexadecimal notation 
and the ability to look at the internal process identification (PID) number of 
another process. The new commands include ;Q, used to validate queues, and ;I, 
used to locate and display information about the current main image. For the 
Delta Debugger, the ;I command can also display information about all shareable 
images activated by the current main image. For more information about how the 
Delta/XDelta Debugger operates on OpenVMS AXP systems, see the OpenVMS 
Delta/XDelta Debugger Manual. 

4.3.7 OpenVMS AXP System-Code Debugger 

OpenVMS AXP supports a new programming tool, the OpenVMS AXP System- 
Code Debugger, that can be used to debug nonpageable system code and device 
drivers running at any IPL. 

The OpenVMS AXP System-Code Debugger is a symbolic debugger. You can 
specify variable names, routine names, and so on, precisely as they appear in 
your source code. You can also display the source code where the software is 
executing and step through it by source line. 
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You can use this debugger to debug code written in the following languages: 

• C 

• Bliss 

• VAX MACRO 


_ Note _ 

A Bliss compiler is not available for OpenVMS AXR 


The OpenVMS AXP System-Code Debugger recognizes the syntax, data typing, 
operators, expressions, scoping rules, and other constructs of a given language. 

If your program is written in more than one language, you can change the 
debugging context from one language to another during a debugging session. 

For more information about Step 2 drivers and the OpenVMS AXP System-Code 
Debugger, see the OpenVMS AXP Device Support: Developer's Guide. 

4.3.8 System Dump Analyzer 

The System Dump Analyzer (SDA) utility on OpenVMS AXP systems is almost 
identical to the utility provided on OpenVMS VAX systems. Most commands, 
qualifiers, and displays are identical, although there are some additional 
commands and qualifiers, including several for accessing functions of the Crash 
Log Utility Extractor (CLUE) utility. Some displays have been adapted to show 
information specific to OpenVMS AXP systems, such as processor registers and 
data structures. 

While the SDA interface has changed only slightly, the contents of VAX and AXP 
dump files and the entire process of analyzing a system crash from a dump differ 
significantly between the two computers. The AXP execution paths leave more 
complex structures and patterns on the stack than VAX execution paths do. 

To use SDA on a VAX computer, you must first familiarize yourself with the 
OpenVMS calling standard for VAX systems. Similarly, to use SDA on an AXP 
system, you must familiarize yourself with the OpenVMS calling standard for 
AXP systems before you can decipher the pattern of a crash on the stack. 

The changes to SDA include the following: 

— The displays of the SHOW CRASH and SHOW STACK commands contain 
additional information that make debugging fatal system exception bugchecks 
simpler. 

— The SHOW EXEC command display includes additional information about 
executive images if they were loaded using image slicing. Slicing is a 
function performed by the executive image loader for executive images and by 
the OpenVMS Install utility for user-mode images. Slicing an executive image 
(or a user-mode image) greatly improves performance by reducing contention 
for the limited number of translation buffer entries. 

— The MAP command, a new SDA command, enables you to map an address in 
memory to an image offset in a map file. 

— A new symbol, FPCR, has been added to the symbol table. This symbol 
represents a floating point register. 
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4.3.9 Crash Log Utility Extractor 

The Crash Log Utility Extractor (CLUE) is a tool for recording a history of 
crash dumps and key parameters for each crash dump and for extracting and 
summarizing key information. Unlike crash dumps, which are overwritten 
with each system crash and are available only for the most recent crash, the 
crash history file (on OpenVMS VAX) and the summary crash history file with a 
separate listing file for each crash (on OpenVMS AXP), are permanent records of 
system crashes. 

The implementation differences between OpenVMS VAX and OpenVMS AXP are 
shown in Table 4-3. 


Table 4-3 CLUE Differences Between OpenVMS VAX and OpenVMS AXP 



OpenVMS VAX 

OpenVMS AXP 

Attribute 

Access method 

Invoked as a separate utility. 

Accessed through SDA. 

History file 

A cumulative file that contains a 
one-line summary and detailed 
information from the crash dump 
file for each crash. 

A cumulative file that contains only 
a one-line summary for each crash 
dump. The detailed information 
for each crash is put in a separate 
listing file. 

Uses in addition 
to debugging 
crash dumps 

None. 

CLUE commands can be used 
interactively to examine a running 
system. 

Documentation 

OpenVMS System Manager’s 
Manual and OpenVMS System 
Management Utilities Reference 
Manual 

OpenVMS System Manager’s 
Manual and OpenVMS AXP 

System Dump Analyzer Utility 
Manual 


4.3.10 Mathematics Libraries 

Mathematical applications using the standard VMS call interface to the 
OpenVMS Mathematics (MTH$) Run-Time Library (RTL) need not change their 
calls to MTH$ routines when migrating to an OpenVMS AXP system. Jacket 
routines are provided that map MTH$ routines to their math$ counterparts in 
the Digital Portable Mathematics Library (DPML) for OpenVMS AXP systems. 
However, there is no support in the DPML for calls made to JSB routine entry 
points and vector routines. Note that DPML routines are different from those in 
the OpenVMS MTH$ RTL, and you should expect to see small differences in the 
precision of the mathematical results. 

To maintain compatibility with future libraries and to create portable 
mathematical applications, Digital recommends that you use the DPML routines 
available through the high-level language of your choice (for example, DEC 
Fortran or DEC C) rather than using the call interface. Significantly higher 
performance and accuracy are also available to you with DPML routines. 

For more information about the DPML routines, see the Digital Portable 
Mathematics Library manual. 
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Your application may need to determine whether it is running on an OpenVMS 
VAX system or an AXP system. From within your program, you can obtain 
this information by calling the $GETSYI system service (or the LIB$GETSYI 
RTL routine), specifying the ARCH_TYPE item code. When your application is 
running on a VAX computer, the $GETSYI system service returns the value 1. 
When your application is running on an AXP computer, the $GETSYI system 
service returns the value 2. 

Example 4-1 illustrates how to determine the host architecture in a DCL 
command procedure by calling the F$GETSYI lexical function and specifying the 
ARCH_TYPE item code. For an example of calling the $GETSYI system service 
in an application to determine the page size of an AXP computer, see Migrating 
to an OpenVMS AXP System: Recompiling and Relinking Applications . 

Example 4-1 Using the ARCH_TYPE Keyword to Determine Architecture Type 

$! Determine architecture type 
$ type_symbol = f$getsyi("arch_type") 

$ if type_symbol . eq. 1 then goto ON_VAX 
$ if type_symbol .eq. 2 then goto ON_AXP 
$ ON_VAX: 

$ ! 

$ l Do VAX-specific processing 
$ i 

$ exit 
$ ON_AXP: 

$ ! 

$ 1 Do AXP-specific processing 
$ ! 

$ exit 

Note, however, that the ARCH_TYPE item code is available only on VAX 
computers running OpenVMS VAX Version 5.5 or later. If your application needs 
to determine the host architecture for earlier versions of the operating system, 
use one of the other $GETSYI system service item codes listed in Table 4-4. 


Table 4-4 $GETSYI Item Codes That Specify Host Architecture 


Keyword 

Usage 

ARCH_TYPE 

Returns 1 on a VAX computer; returns 2 on an AXP computer. 
Supported on AXP computers and on VAX computers running 
OpenVMS VAX Version 5.5 or a later version. 

ARCH_NAME 

Returns text string “VAX” on VAX computers and text string “Alpha” 
on AXP computers. Supported on AXP computers and on VAX 
computers running OpenVMS VAX Version 5.5 or a later version. 

HW_MODEL 

Returns an integer that identifies a particular hardware model. All 
values equal to or larger than 1024 identify AXP computers. 

CPU 

Returns an integer that identifies a particular CPU. The value 128 
identifies a system as “not a VAX.” This code is supported on much 
earlier versions of VMS than the ARCH_TYPE and ARCH_NAME 
codes. 
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4.3.12 Uncovering Latent Bugs 

Despite your best efforts, and following all the previous suggestions, you may 
encounter bugs that were in your program all along, but never caused a problem 
on an OpenVMS VAX system. For example, a failure to initialize some variable 
in your program might have been benign on a VAX computer but could produce 
an arithmetic exception on an AXP computer. The same could be true moving 
between any other two architectures, because the available instructions and the 
way compilers optimize them is bound to change. There is no magic answer for 
bugs that have been in hiding, but you should test your programs after porting 
them before making them available to other users. 

4.4 Application Compatibility with Future OpenVMS AXP Releases 

Programs that run on OpenVMS AXP systems will continue to run unmodified on 
future OpenVMS AXP releases, except for those programs that use inner modes 
or are linked against the system symbol table. As on OpenVMS VAX systems, 
you will need to recompile and relink any programs that use inner modes or are 
linked against the system symbol table for them to run on future OpenVMS AXP 
releases. 

4.5 Guidelines for New Program Development 

The following guidelines are provided to facilitate the development of programs 
intended to run on both OpenVMS VAX systems and OpenVMS AXP systems: 

1. Familiarize yourself with the changes and the new features of the DEC 
compiler that you will use. For example: 

• If you are writing any C code with external symbols, familiarize yourself 
with the changes in DEC C to coding external symbols and compiling 
such code. 

• If your program needs to dynamically establish condition handlers, 
you may need to make some changes to your code, as described in 
Section 4.1.2. 

2. Write your code in mid- or high-level languages whenever possible. 

3. Follow good programming practices for program modularity. 

4. Avoid creating any VAX architectural dependencies in your code. One area 
that can be troublesome is that of shared memory. The VAX architecture 
makes certain implicit guarantees about synchronization. If a program 
requires the same synchronization on the Alpha AXP architecture, it must 
request it explicitly. This potential problem and others are briefly described 
in Section 4.1.1. For more information, see Migrating to an OpenVMS AXP 
System: Recompiling and Relinking Applications and the user’s guide for the 
compiler you will use. 

If you cannot avoid relying on the VAX architecture for one or more 
operations, conditionalize your code for each architecture, as shown in 
Example 4-1. 

5. Familiarize yourself with the differences between the linker on OpenVMS 
VAX and the linker on OpenVMS AXP. Some of the differences are described 
in Section 4.3.1. 

6. Examine your OpenVMS VAX build procedures and note what changes may 
be necessary for recompiling and relinking on an OpenVMS AXP system. 
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7. Do not use OpenVMS VAX features that are not yet supported by the 
Open VMS AXP operating system. If in doubt, check with your Digital account 
representative or authorized reseller. 

8. Use at least aligned longwords for in-memory data structures wherever 
possible. This has always been more efficient on VAX computers. On AXP 
computers, the performance difference becomes even greater. 
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DCL Differences Between OpenVMS VAX and 

OpenVMS AXP 


A.1 DIGITAL Command Language (DCL) 

The DIGITAL Command Language (DCL), the standard user interface to 
OpenVMS, remains essentially unchanged with OpenVMS AXP. All commands 
and qualifiers available on OpenVMS VAX are also available on OpenVMS AXP, 
except for a few, as shown in Table A—1. 

Because of architectural differences between VAX and AXP computers, some 
differences exist in the implementation of DCL commands, qualifiers, and lexical 
functions. These differences are noted in Table A—1. 


Table A-1 DCL Differences Between OpenVMS VAX and OpenVMS AXP 


Command/Qualifier 

On VAX 

On AXP 

ANALYZE/IMAGE 

System versions displayed are the 
versions of the system symbol table, 
the image that is linked against the 
executive. 

System versions displayed are the 
versions of the system shareable 
image, the image that is linked against 
the executive. 


Cannot analyze an OpenVMS AXP 
image. 

Can analyze both OpenVMS AXP and 
OpenVMS VAX images. 

ANALYZE/PROCESS 

You use the OpenVMS Debugger to 
analyze the dumped image. 

In some cases, you cannot use the 
OpenVMS Debugger, such as when 
the dumped image’s PC is set to an 
invalid address. Instead, you can use 
the Delta Debugger. 

CLUE 

Invokes CLUE. 

CLUE commands are accessed through 
SDA. For more information, see 

Section 4.3.9. 

DIAGNOSE 

Not available; under investigation. 

Invokes the DECevent utility and 
selectively reports the contents of one 
or more event log files. 

FONT 

Converts an ASCII bitmap 
distribution format (BDF) into binary 
server natural form (SNF). 

Converts an ASCII bitmap distribution 
format (BDF) into binary portable 
compiled format (PCF). 

INITIALIZE 
/STRUCTURE=level 

Supports Files-11 On-Disk Structure 
Level 1 Disks. 

Does not support Files-11 On-Disk 
Structure Level 1 Disks. 



(continued on next page) 
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Table A-1 (Cont.) DCL Differences Between OpenVMS VAX and OpenVMS AXP 

Command/Qualifier On VAX On AXP 


MACRO/ALPHA 

Not available. 

MACRO/MIGRATION 

Not available. 

MOUNT 

Supports Files—11 On-Disk Structure 
Level 1 Disks. 

PATCH 

Invokes the Patch utility. 

RECALL 

Displays up to 20 previously entered 
commands. 

RECALL 

/INPUT=filespec 

Not yet available; planned. 

RECALL 

/OUTPUT=filespec 

Not yet available; planned. 

RE CALL/PAGE 

Not yet available; planned. 

SET HOST/DUP 

Commands for installing FYDRIVER 
differ from AXP. 

SET HOST/LAT 
/AUTOPROMPT 

Not yet available; planned. 

SET HOST/LAT/QUEUE 

Not yet available; planned. 

SET PASSWORD 

The random password generator 
differs from that on AXP. One 
difference is that the passwords 
presented on VAX are hyphenated. 

SET TERMINAL 
/PROTOCOL=DDCMP 

Controls whether the terminal 
port specified is changed into an 
asynchronous DDCMP line. 

SET TERMINAL 
/SWITCH=DECNET 

Causes the terminal lines at 
each node to be switched to 
dynamic asynchronous DDCMP 
lines when specified with the 
/PROTOCOL=DDCMP qualifier. 

SHOW MEMORY/GH 
REGIONS 

Not available. 

SHOW MEMORY 
dynamic memory 
parameter 

Each dynamic memory area displayed 
in bytes and pages. 


Invokes the native MACRO-64 
assembler, if installed. For more 
information, see Section 4.3.3. 

Invokes the MACRO-32 compiler. For 
more information, see Section 4.3.2. 

Does not support Files-11 On-Disk 
Structure Level 1 Disks. 

Not available; limited functionality 
under investigation. 

Displays up to 254 previously entered 
commands. 

Causes each line of the input file to be 
added to the recall buffer. 

Specifies the name of the output file 
where the contents of the recall buffer 
are written. 

Controls whether output from the 
RECALL command is displayed one 
screen at a time. 

Commands for installing FYDRIVER 
differ from VAX. 

Causes an OpenVMS Username: 
prompt to be automatically displayed 
when a SET HOST/LAT command is 
issued. 

When connecting to a reverse LAT 
service that is already in use (such as 
a dial-out modem), you are notified 
that the service is in use, and the SET 
HOST/LAT command terminates. 

The random password generator 
presents passwords that are not 
hyphenated. For more information, 
see Section 1.4.6. 

Not available. 


Not available. 


Displays information about the 
granularity hint regions (GHR) that 
have been established. 

Each dynamic memory area displayed 
in pagelets. 


(continued on next page) 
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Table A-1 (Cont.) DCL Differences Between OpenVMS VAX and OpenVMS AXP 


Command/Qualifier 

On VAX 

On AXP 

Working set qualifiers 
such as AVSDEFAULT, 
/WSEXTENT, and 
/WSQUOTA 

Specified in units of 512-byte pages 

Specified in units of 512-byte pagelets, 
rounded to the nearest CPU-specific 
page. For more information, see 
Section 1.5.1.7. 

Lexical Functions 

On VAX 

On AXP 

F$CONTEXT 

Base priority valid range 0-31. 

Base priority valid range 0-63. 

F$GETSYI 

For CPU, the integer that identifies 
the processor type is stored in the 
processor’s system identification (SID) 
register. 

For CPU, the integer that identifies 
the processor type is stored in the 
hardware restart parameter block 
(HWRPB). 


For HW_MODEL, the integer that 
identifies the model type is less than 
or equal to 1023 

For HW_MODEL, the integer that 
identifies the model type is greater 
than 1023 
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Ada, 1-11 
Aliases 

See Cluster aliases 

Alpha AXP Applications Catalog , 1-9, 3-3 
Alpha Migration Centers (AMCs) 

See Business Partner Development Assistance 
centers 

Alpha Resource Centers (ARCs) 

See Business Partner Development Assistance 
centers 

ANALYZE/IMAGE command, A-l 
ANALYZE/PROCESS command, A-l 
Application compatibility 

nonprivileged applications, 4-13 
privileged applications, 4-13 
with future OpenVMS AXP releases, 4-13 
Applications 

assessing portability, 4—1 
available third-party, 3-5 
catalog, 3-3 
Digital, 3-3 

guidelines for new program development, 4-13 
mixing native AXP and translated images, 

3-11 

recompiling and relinking documentation, 3-11 
VAX dependency checklist, 4-2 
Architecture 

atomic operations, 1-10 
CISC, 1-10 
dependencies, 4-2 
differences, 1-10 
RISC, 1-10 

semantic guarantees, 1—10 
ARCH_NAME keyword 

determining host architecture, 4-12 
ARCH_TYPE keyword 

determining host architecture, 4-12 
Assembler 

MACRO-64, 1-11 
AST routine, 1—10 

parameter list dependence, 4-2 
AUTOGEN command procedure, 1-4 


Availability of products 

base operating system features, 3-1 
Digital optional software products, 3—3 
third-party applications, 3-5 

B_ 

Backup operations, 1-4 
BASIC, 1-11 
BPDA centers 

See Business Partner Development Assistance 
centers 

Buffer size, 4—2 
Bugs 

latent, 4-13 

Business Partner Development Assistance centers 
(BPDA), 3-10 
Bus support, 2-2 

C_ 

C, 1-11 

header files for defining macros, 4-5 
LIB$ESTABLISH, 4-3 
C++, 1-11 

C2 security features, 1-7 
Card reader driver, 1-7 
Catalog 

optional software products, 1-9 
third-party applications, 1-9 
CISC architecture, 1-10 
CLUE (Crash Log Utility Extractor) 

See Crash Log Utility Extractor 
Cluster aliases 

supported with DECnet on OpenVMS AXP 
systems, 2-5 
COBOL, 1-11 
Command procedures, 1-2 

system startup on OpenVMS AXP, 1-5 
system startup on OpenVMS VAX, 1-5 
Compatibility of images 

mixing native and translated images, 3-11 
Compilers, 1-11 

architectural differences, 4-5 
DEC Ada, 1-11 
DEC BASIC, 1-11, 3-3 
DEC C, 1-11 
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DEC C++, 1-11 
DEC COBOL, 1-11 
DEC Fortran, 1-11 
DEC OPS5, 1-11 
DEC Pascal, 1-11 
DEC PL/I, 1-11 
differences, 4-3 
MACRO-32, 1-11 
PALcode built-ins, 4—5 
release of, 3-3 
use of LIB$ESTABLISH, 4-3 
Condition handlers, 4-2 
establishing dynamic, 4-3 
Configuring the DECnet database, 2-5 
CPU keyword 

determining the host architecture, 4-12 
Crash Log Utility Extractor (CLUE), 1-12, 4-11, 
A-l 

Custom Project Service, 3-10 

D_ 

Data 

shared access, 4-2 
Databases 

on Open VMS AXP systems, 1-2, 3-5 
Data packing, 4-2 
Data types 

D_float floating-point, 1-10 
G_float floating-point, 1—10 
H_float floating-point, 1-10, 4-2 
not supported, 1-10 

DCL (DIGITAL Command Language), 1-2, A-l 
help, 1-2 
Debugger 

Delta/XDelta, 1-12, 4-9 
differences, 1-12 
OpenVMS, 1-12,4-9 
OpenVMS AXP System-Code, 1-12, 4-9 
DEC Ada 
See Ada 
DEC BASIC 
See BASIC 
DEC C 
See C 
DEC C++ 

See C++ 

DEC COBOL 
See COBOL 
DECdns, 1—8 
DECdtm, 1—8 
DECevent utility, 1—9, A—1 
DECforms, 1-2 
DEC Fortran 
See Fortran 


DECmigrate for OpenVMS AXP, 1-4, 1-11 
documentation, 3-11 
vector instructions, 1-13 
DECnet for OpenVMS 

cluster alias supported, 2-5 
DECnet object, 2-4 
Phase IV, 2-1 
DECnet Phase V 
See DECnet/OSI 

DECnet Test Sender/DECnet Test Receiver utility, 
2-4 

DECnet-VAX, 2-1 
DEC OPS5 
See OPS5 
DEC Pascal 
See Pascal 
DEC PL/I 
See PL/I 

DEC Rdb for OpenVMS 
See Rdb 

DEC TCP/IP Services for OpenVMS 
See TCP/IP Services for OpenVMS 
DECwindows Motif, 1-3 
DEC X.25 Client for OpenVMS AXP 
See X.25 Client for OpenVMS AXP 
Delta/XDelta Debugger 
differences, 1-12 
OpenVMS AXP, 4-9 
Detailed Analysis Service, 3-9 
Device drivers 
debugging, 4-9 
documentation, 3-12 
loading, 1-9 
Step 1 interface, 4-8 
Step 2 interface, 4-8 
user written, 1—11, 4-8 
written in C, 4-8 
Diagnostic features 
compilers, 4-4 
VEST, 4-4 

Digital Portable Mathematics Library 
See DPML 
Disk quotas, 1-4 
Documentation 

how to order, 3-13 

Documentation comments, sending to Digital, iv 

Downline loading, 2—4 

DPML 

compatibility, 4-11 
Drivers 

See Device drivers 

DTS/DTR (DECnet Test Sender/DECnet Test 
Receiver utility) 

See DECnet Test Sender/DECnet Test Receiver 
utility 
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Dump files 

analyzing, 4-10 
DVNETEND PAK 

DECnet end-node license, 2-5 
DVNETEXT PAK 

DECnet for OpenVMS AXP extended license, 
2-6 

DVNETRTG PAK 

DECnet for OpenVMS VAX routing license, 2-6 
Dynamic load balancing, 1-8 
D_float floating-point data type, 1-10 

E_ 

Editors 

OpenVMS AXP, 1-3 
OpenVMS VAX, 1-3 
End-user’s environment, 1-2 
OpenVMS AXP, 1-2 
OpenVMS VAX, 1-2 
Ethernet monitor (NICONFIG), 2-5 
Event logging, 2-4 
Executive images 
slicing, 4-10 

F_ 

F$CONTEXT, A-3 
F$GETSYI, A-3 
FAL (file access listener) 
on AXP, 2-5 
Fastboot, 1-8 

FDDI (Fiber Distributed Data Interface) 
support on AXP, 2—5 

Feedback on documentation, sending to Digital, iv 
Fiber Distributed Data Interface (FDDI) 

See FDDI 
File access listener 
See FAL 
File names 

changes, 1—5 
File transfers 

DECnet network, 2-1 
TCP/IP network, 2-2 
with FAL, 2—5 
File types 

on AXP systems, 4—5 
FONT command, A-l 
Fonts 

scalable, 1-3 
Fortran, 1-11 

/CHECK qualifier, 4-4 
LIB$ESTABLISH, 4-3 
Full names, 1-8 
FYDRIVER 

installing, A-2 


G_ 

$GETSYI system service 

determining host architecture, 4-12 
Guidelines 

new program development, 4-13 
G_float floating-point data type, 1—10 

H_ 

Help 

DCL, 1-3 
messages, 1-3 
Help Message utility, 1-3 
HW_MODEL keyword 

determining the host architecture, 4—12 
H_float floating-point data type, 1-10, 4-2 

| _ 

I/O subsystem 

configuration commands, 1-4 
Image compatibility 

mixing native and translated images, 3-11 
Images 

creating, 4—5 

INITIALIZE/STRUCTURE command, A-l 

Interconnect support, 2-3 

Internet 

accounts for AXP systems, 3-14 
Interoperability 

of native AXP and translated images, 3-11 
on a network, 2-1 
Investment protection 
hardware, 3-8 
software, 3—8 

L_ 

Lexical functions, A—3 
LIB$ESTABLISH, 4-3 
Librarian utility 
differences, 1-12 
Lineage 

OpenVMS AXP operating system, 1-1 
Linker, 1—12 

differences, 1-12 

features specific to OpenVMS AXP, 1—12, 4—6 
Linking 

creating native AXP images, 4-5 
Logging events, 2-4 
Login 

remote, 2-1 

Loopback mirror testing, 2-5 
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M _ 

MACRO-32 compiler, 1-11, 4-7 
documentation, 3-11 
MACRO-64 assembler, 1-11, 4-8 
MACRO/ALPHA command, A-l 
See also MACRO-64 assembler 
MACRO/MIGRATION command, A-2 
See also MACRO-32 compiler 
Maintenance procedure 
menu-driven, 1-4 
Mathematic routines 
compatibility, 4-11 
Migration documentation, 3—11 
Migration paths 
application, 3-8 
Migration planning 
documentation, 3-11 
services, 3-9 
Migration services 

Custom Project Service, 3-9 
Detailed Analysis Service, 3-9 
how to order, 3—9 
Migration Support Service, 3-9 
Orientation Service, 3—9 
Project Planning Service, 3-9 
Migration software, 3-10 
Migration Support Service, 3-9 
Migration training, 3-10 
how to order, 3-10 

Mixing native AXP and translated images 
as a stage in migration, 3-11 
possibility of, 3-11 
MONITOR POOL command, 1-5 
Monitor utility (MONITOR), 1-5 
MOUNT command, A-2 
MTH$ routines 

compatibility, 4—11 

N_ 

NETCONFIG.COM procedure, 2-5 
NETCONFIG_UPDATE.COM procedure, 2-5 
Network 

file transfers on TCP/IP network, 2-2 
interfaces, 2-2 
protocols, 2-2 

starting access procedure, 2-5 
Network management tasks 

differences on AXP and VAX, 2-5 
DECnet/OSI for OpenVMS, 2-1 
routing support, 2-5 
similarities on AXP and VAX, 2-4 

configuring the DECnet database, 2-5 
DECnet cluster alias, 2-5 
DECnet objects and associated accounts, 
2-4 


Network management tasks 

similarities on AXP and VAX (cont’d) 
downline loading, 2-4 
DTS/DTR, 2-4 

DVNETEND end-node license, 2-5 
end-node support, 2-5 
Ethernet monitor (NICONFIG), 2-5 
Ethernet support, 2-5 
event logging, 2-4 
FDDI support, 2-5 
file access listener, 2-5 
file transfer, 2-5 
loopback mirror testing, 2—5 
NETCONFIG.COM, 2-5 
NETCONFIG_UPDATE.COM, 2-5 
network size, 2—5 
node name rules, 2-5 
SET HOST capabilities, 2-5 
starting network access, 2-5 
STARTNET.COM, 2-5 
task-to-task communication, 2-5 
upline dump, 2-4 
Network size 

comparison on AXP and VAX, 2-5 
NICONFIG 

Ethernet monitor, 2—5 
Node name rules, 2-5 

O_ 

OpenVMS AXP operating system 
diagnostic features, 4-4 
lineage, 1-1 
portability features, 4-4 
OpenVMS AXP System-Code Debugger, 4-9 
OpenVMS Debugger 
See Debugger 

OpenVMS Mathematics Run-Time Library 
compatibility, 4-11 
OPS5, 1-11 

Optional software products 
catalog, 1-9 

startup procedures that include, 1-9 
Order information 

documentation, 3-13 
migration services, 3-9 
migration training, 3-10 
Orientation Service, 3-9 

p_ 

Pagelets 
size, 1-6 
Pages 

in a VMScluster system, 1-6 
size, 1-6 
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PAKs (Product Authorization Keys) 

DVNETEND DECnet end-node license on AXP 
and VAX, 2-5 

DVNETEXT DECnet for OpenVMS AXP 
extended license, 2-6 

DVNETRTG DECnet for OpenVMS VAX routing 
license, 2-6 
PALcode, 4-5 
Pascal 

LIB$ESTABLISH, 4-3 
Password generator, 1-3 
Passwords 

on OpenVMS AXP, 1-3 
PATCH command, A-2 
See also Patch utility 
Patch utility, 1-7, 1-8 

PCSI (POLYCENTER Software Installation utility) 
See POLYCENTER Software Installation utility 
Performance 

of translated images, 3-11 
PL/I, 1-11 

POLYCENTER Software Installation utility, 1-4, 
1-9 

Porting checklist, 4-2 
Processor type identifier 
AXP, A-3 
VAX, A-3 

Programming environment 

differences on AXP and VAX, 1-10 
similarities on AXP and VAX, 1—10 
Project Planning Service, 3-10 
Protocols, 2-2 
Proxy database, 1-8 
Proxy services, 1-8 

Q_ 

Queuing 

tagged command, 1-8 

R_ 

RECALL command, A-2 
Remote login 

DECnet network, 2-1 
TCP/IP network, 2-2 
Remote monitoring 

mixed-version VMScluster systems, 1-5 
Remote nodes 

monitoring, 1-5 
Restore operations, 1-4 
RISC architecture, 1-10 


S_ 

SCSI-2 devices 

programming support, 1-8 
SCSI port interface (SPI$), 1-8 
SDA 

See System Dump Analyzer 
Security features, 1-7 
Security server, 1-8 
SET HOST command, A-2 

on OpenVMS AXP systems, 2-5 
SET PASSWORD command, A—2 
See also Password generator 
SET TERMINAL command, A-2 
SHOW MEMORY command, 1-5, A-2 
Sliced images, 4—10 
SMP systems 

dynamic load balancing, 1—8 
Snapshot facility (Snapshot), 1-7, 1-8 
Standalone Backup utility, 1-4 
Starting network access, 2—5 
STARTNET.COM procedure, 2-5 
Symbol vectors 

declaring universal symbols, 4—5 
SYSGEN (System Generation utility) 

See System Generation utility 
SYSMAN (System Management utility) 

See System Management utility 
System Dump Analyzer (SDA) 
differences, 1-12 
OpenVMS AXP, 4-10 
SHOW POOL command, 1-5 
System Generation utility (SYSGEN), 1-4 
System management differences on AXP and VAX 
availability of optional software products, 1-9 
disk quotas, 1—4 
file names, 1-5 

I/O commands in SYSMAN, 1-4 
MONITOR POOL command, 1-5 
page size, 1-6 
Patch utility, 1-7 
VMScluster support, 1-7 
System management similarities on AXP and VAX, 
1-3 

System Management utility (SYSMAN), 1—4 

T_ 

Tagged command queuing, 1-8 
Task-to-task communication, 2—5 
TCP/IP Services for OpenVMS, 2-1, 2-2, 2-3 
Training 

migration, 3—10 
Translated images 

performance of, 3-11 
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ucx 

See TCP/IP Services for OpenVMS 
Unaligned data 

reduced performance, 3-11 
Upline dumping, 2-4 
User-mode images 
slicing, 4—10 

User-written device drivers 

on OpenVMS AXP systems, 4-8 

V_ 

VAX dependency checklist, 4-2 
VAX Environment Software Translator 
See VEST 
VAX instructions 

reduced performance, 3-11 
VAX MACRO 


See also MACRO-32 compiler 
LIB$ESTABLISH, 4-3 

recompiling on OpenVMS AXP systems, 4-7 
Vector processing, 1-12 

Fortran applications, 1-12 
VAX MACRO applications, 1—12 
VEST (VAX Environment Software Translator), 
1-4, 3-10 

See also DECmigrate for OpenVMS AXP 
documentation, 3-12 
VMScluster system, 2-1 

cluster aliases supported on OpenVMS AXP 
systems, 2-5 

configuration support, 2-6 
interoperability, 2—6 
VMS/ULTRIX Connection 

See TCP/IP Services for OpenVMS 

w_ 

Working set qualifiers, A-2 
WSDEFAULT qualifier, A-2 
WSEXTENT qualifier, A-2 
WSQUOTA qualifier, A-2 
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X.25 Client for OpenVMS AXP, 2-2, 2-6 
X.25 support, 2-2, 2-6 
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How to Order Additional Documentation 


Technical Support 

If you need help deciding which documentation best meets your needs, call 800-DIGITAL (800-344-4825) 
and press 2 for technical assistance. 


Electronic Orders 

If you wish to place an order through your account at the Electronic Store, dial 800-234-1998, using a 
modem set to 2400- or 9600-baud. You must be using a VT terminal or terminal emulator set at 8 bits, no 
parity. If you need assistance using the Electronic Store, call 800-DIGITAL (800-344-4825) and ask for an 
Electronic Store specialist. 


Telephone and Direct Mail Orders 


From 


Call 


Write 


U.S.A. 


Puerto Rico 


Canada 


International 


Internal Orders 1 
(for software 
documentation) 


Internal Orders 
(for hardware 
documentation) 


DECdirect 

Phone: 800-DIGITAL 
(800-344-4825) 

Fax: (603) 884-5597 

Phone: (809) 781-0505 
Fax: (809) 749-8377 


Phone: 800-267-6215 
Fax: (613) 592-1946 


DTN: 264-3030 
(603) 884-3030 
Fax: (603) 884-3960 


DTN: 264-3030 
(603) 884-3030 
Fax: (603) 884-3960 


Digital Equipment Corporation 
P.O. Box CS2008 
Nashua, NH 03061 


Digital Equipment Caribbean, Inc. 

3 Digital Plaza, 1st Street 

Suite 200 

Metro Office Park 

San Juan, Puerto Rico 00920 

Digital Equipment of Canada Ltd. 
100 Herzberg Road 
Kanata, Ontario, Canada K2K 2A6 
Attn: DECdirect Sales 

Local Digital subsidiary or 
approved distributor 

U.S. Software Supply Business 
Digital Equipment Corporation 
10 Cotton Road 
Nashua, NH 03063-1260 

U.S. Software Supply Business 
Digital Equipment Corporation 
10 Cotton Road 
Nashua, NH 03063-1260 


1 Call to request an Internal Software Order Form (EN-01740-07). 
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